The ontology is the product

Ask an enterprise AI system about a "customer" and you will usually get an answer. Ask the organisation what a customer is and you will get four. The billing system means a paying account. The CRM means a contact at a company. The warranty system means whoever registered the product. The analytics team means a household. The model was asked a question with four meanings, retrieval returned the wrong one, the agent acted on it, and a person caught it late or not at all.

That is the shape of most of the failures I am called into, and it is why I have come to think of the ontology, not the model, as the product in enterprise AI. The model is rented. The ontology is the part the organisation owns, the part that outlasts any vendor, and the part that decides whether anything built on top of it can be trusted.

Close

Three layers. At the bottom, systems of record (ERP, CRM, tickets, documents). In the middle, the ontology: entities, relationships, rules and actions with their definitions. At the top, the consumers: retrieval, agents, dashboards and people, all reading the same definitions.

Three things that get called an ontology

The word is used loosely, so it is worth separating three things that are often confused. The boundaries are sharper in this list than in practice, where a good semantic layer grows relationships and a context graph is usually built on an ontology, but the purposes are distinct and that is what matters when you decide what to build.

A semantic layer is a model of calculations. It is the YAML or LookML that says what "net revenue" means so that every dashboard computes it the same way. It exists for people reading charts. It knows nothing about relationships, exceptions or why. The essay Ontologies, Context Graphs and Semantic Layers puts it well: meaning is not the same as measurement.

An ontology is a model of meaning. It defines the classes of things in a domain, the properties those things have, the relationships between them, and the rules that constrain them. In its formal form it is written in standards like RDF, OWL and SKOS, with SHACL for validation, and it supports inference: if every approved supplier must have a current audit, and this supplier's audit expired, then this supplier is not approved, and a system can derive that without being told. The large public ontologies, SNOMED CT in healthcare with some 350,000 concepts, the Gene Ontology in biology, have run for decades on this basis.

A context graph adds the why. It records that a particular order was approved despite breaching standard terms, and who approved it, and on what reasoning. It is the audit trail made queryable, and it is what an agent needs when it must act in line with precedent rather than policy alone.

Palantir's commercial success has made the word fashionable. Its Ontology is a governed, typed, live model of the enterprise: objects, properties, links, and, importantly, actions, meaning the operations a user or an agent is allowed to perform on those objects, with the security policy attached. Gartner wrote in July 2026 that agentic AI without a context layer of this kind struggles to run reliably in real enterprise environments. I agree with the conclusion and I want to argue for a much smaller version of it than the platform vendors sell.

Why the failures are definitional

Language models are good at language. They are not good at knowing which of an organisation's private meanings applies. Retrieval does not fix this, because retrieval returns documents, and documents carry the ambiguity with them. Fine-tuning does not fix it either, because the ambiguity is in the organisation, not the model.

In practice the failure shows up in three places.

Retrieval returns the wrong thing. The query says "open orders for this customer", the index contains four systems' views of the customer, and the top result is the one with the best lexical match rather than the one the business means.

The agent acts on it. An agent given tools and a goal will take the most plausible path. If "cancel the order" means different things in the order system and the fulfilment system, the agent will choose one and be confident about it.

Nobody can check it. Without a written definition, the human reviewer has no reference to check the model's answer against. Review becomes a matter of whether the output looks reasonable, which is the weakest control there is.

The common thread is that the definitions existed in people's heads and in scattered glossaries, not in a form that models, agents and reviewers could all read. An ontology is just those definitions written down once, in a form that can be enforced.

Small enough to own

Here is where I part company with the platform approach. Most enterprises do not need an ontology of the whole business. They need an ontology of the decision they are trying to automate, and that is a few dozen entities, not a few thousand.

The rule I apply is that the ontology is scoped to one bounded use case and is owned by the client team that owns the use case, and that it stays small enough for that team to maintain without a specialist. I came to it through the data work on an enterprise AI build for a two-wheeler manufacturer, where the useful predictive signals only appeared after the entities and events had been modelled properly from the historical data, and where the modelling, not the model, was what the business could later own. In practice the rule means:

1. Start from the systems of record, not from a whiteboard. The entities are already there as tables and fields. The work is deciding which fields define the entity, which systems are authoritative for which properties, and where two systems disagree.
2. Write the definitions in plain language first. "An active customer is an account with at least one invoice in the last twelve months and no termination record." Then encode it. If the plain-language definition cannot be agreed in a meeting, no encoding will fix that.
3. Attach the rules that matter to the decision. Not every rule in the business, only the ones the AI system will act on or be checked against. Approval thresholds, exclusion criteria, the conditions under which a case must go to a person.
4. Tie every definition to its source. Each entity and rule points at the system and field it came from, so that when the source changes, the ontology is known to be stale.
5. Make it testable. A definition is a test. "Active customer" implies a query that returns the set of active customers; the model's answers can be checked against that set. The ontology becomes the ground truth for evaluation, which is the second reason to build it.

This is not a diagram. It is a small, versioned artefact, often a few hundred lines, that a developer can read, that an agent can load as a constraint, and that a reviewer can hold the output against.

To make that concrete, here is the shape of one for a supplier-onboarding use case, stripped to what the automation touches. It is illustrative, not a client's.

entities:
  Supplier:
    source: erp.vendor_master            # authoritative for identity
    key: vendor_id
    properties: [registered_name, tax_id, country, bank_account, status]
    states: [prospective, under_review, approved, suspended]
  Certificate:
    source: documents.supplier_certs
    properties: [type, issuer, valid_from, valid_to]
    belongs_to: Supplier
rules:
  approved_requires:                      # testable: a query over the sources
    - Supplier.tax_id matches tax_registry
    - count(Certificate where type in [ISO9001, insurance] and valid_to > today) == 2
    - Supplier.bank_account verified_by finance
actions:
  approve_supplier:
    allowed_when: Supplier.status == under_review and approved_requires all true
    performed_by: procurement_officer     # never by the agent
  suspend_supplier:
    allowed_when: Supplier.status == approved
    performed_by: procurement_officer
agent_may:
  read: [Supplier, Certificate, tax_registry]
  propose: [approve_supplier]            # propose, not perform
  write: []

Forty lines, and it already does three jobs: it tells retrieval which system answers "is this supplier approved", it gives the agent a rule it can check and an action it may only propose, and it gives the officer the exact conditions to review against. Every line points at a source, so when finance renames the bank-verification field, the ontology fails its own test and someone finds out before the agent does.

How agents use it

An ontology does three jobs in an agent architecture, and they are different enough to be worth naming.

As a retrieval guide, it tells the system which source is authoritative for which question, so that "open orders" is answered from the order system and not from a document that mentions orders. This alone removes a large share of the wrong-answer cases I see.

As a constraint, it bounds what an agent can do. If the ontology says an order in state "shipped" has no "cancel" action, the agent should not be able to cancel it. The word "should" is doing work there: the ontology defines the rule, and something at runtime has to enforce it, a tool layer that refuses the call, a policy check before the action, a permission the agent does not hold. An ontology nobody enforces is documentation. Encoding actions alongside entities, which is the part of Palantir's design I think everyone should copy, is what makes the enforcement possible; the harness is what makes it real.

As a reference for review, it gives the human a definition to check against. A reviewer who can see that the system classified this supplier as approved, and can see the rule for approval, can check the answer in seconds. A reviewer with only the answer cannot.

How I would build it into a platform

If I were designing the semantic layer of an enterprise analytics or agentic platform today, rather than a single use case, this is the shape I would argue for. It is a position, not a product I have shipped end to end, and I would expect to revise it.

1. Ontology as code, in the same repository as the agents. A versioned set of files, reviewed like code, with a test suite that runs on every change and queries the systems of record to prove that each definition still holds. A definition that cannot be tested does not go in.
2. Derived from the systems, written by the owners. Entities and properties are generated from schemas and catalogues and kept in sync automatically. Definitions and rules are written by the people who own the process, in plain language first, then encoded. The platform's job is to make that cheap, not to guess.
3. Agents consume it as tool schemas and permissions, not as prose. The ontology compiles into the agent's tool definitions, the allowed actions per entity state, and the retrieval routing. The agent never reads the ontology as a document; it is constrained by it.
4. A knowledge graph only where relationships are queried. Most use cases need entities, definitions and rules; they do not need a graph database. Build the graph when an agent or an analyst has to traverse relationships several hops deep, and keep it in step with the sources by regenerating it rather than editing it.
5. The ontology is the evaluation ground truth. Every definition yields a set; every rule yields a test. The evaluation harness for the agents is generated from the same files, so the agent is measured against the business's own definitions rather than a rubric written on the side.
6. One owner per entity, named in the file. When the source changes, the owner is the person who gets the failing test.

The practical consequence is that the ontology, not the model and not the platform, becomes the thing the organisation accumulates. Models will be swapped. The definitions, once tested and owned, stay.

What I am still working out

Two questions are open on my Research page and I will not pretend they are settled.

The first is derivation. How much of an ontology can be pulled automatically from schemas, glossaries and the organisation's own documents, and how much needs a person in a room? My current view is that the entities and properties derive well, the definitions derive badly, and the rules do not derive at all; they have to be stated by someone who owns them.

The second is drift. An ontology that falls out of step with the systems it describes is more dangerous than none, because it is trusted. Keeping it in step is a data engineering problem as much as a modelling one, and the answer probably involves treating the ontology as code: versioned, tested against the sources on every change, and failing loudly when a field it depends on disappears.

Where to start

If you have an AI pilot that works in the demo and fails in the workflow, the first thing I would check is not the model, the prompts or the retrieval. It is whether the two or three entities at the centre of the use case have one agreed definition, written down, tied to a system of record, and testable. If they do not, that is the work, and it is cheaper than any amount of model tuning. It is also the work that stays with you when the model changes, which, in this field, it will.

This is the same reason the Architecture Sprint produces a solution architecture with data and integration boundaries before any code is written: the boundaries are the ontology, and they are the part of the system that has to be right first.