Skip to content
Personal Learning Notes
10 min read

An ontology is not a knowledge graph: what enterprise AI actually needs one for

Where the line runs between an ontology, a knowledge graph, a database schema, a workflow and an agent — and why I think enterprises should never build a top-down global ontology, but derive one backwards from the actions their agents are allowed to take.

When I wrote about Glean, my conclusion was that the moat in enterprise AI is not the model — it is permissions and context. One question stayed with me afterwards. A context layer solves “the AI can find it”, but the thing that actually blocks me when building an agent runtime is the step after that: the AI found the record. Now what? On what basis does it know whether that record may be changed, or whether this action may be executed at all?

Follow that one layer down and you land on a word that has been around for twenty-odd years and has suddenly come back into circulation: ontology.

Most of the current discussion smears ontologies, knowledge graphs, database schemas and workflows into one another. So: boundaries first, then my two actual claims — what changed for ontologies in the AI era, and how most enterprises should build one. Especially how they should not.

Separating the words that keep getting used interchangeably

The definition most often cited in computing comes from Tom Gruber’s 1993 paper: an ontology is “an explicit specification of a conceptualization”. Abstract, but the load-bearing word is explicit — taking the conceptual agreements that live in people’s heads and in custom, and writing them down in a form a machine can read.

Inside a company, the division of labour looks like this:

Thing Question it answers Typical form
Database schema How is the data stored? Tables, columns, foreign keys
Knowledge graph What happened in the world? (facts) Triple instances
Ontology What exists, and what may it become? (definitions) Object types, relations, states, actions, constraints, permissions
Workflow Where do we go next? Flowcharts, state machines
Rules engine What to do when a condition holds IF / THEN
Digital twin How are things right now? Live state mirror
Agent How do I do this particular task? Planning plus tool calls
Prompt What context comes along this turn? Semantics with a lifespan of seconds

The pair that gets confused most often is ontology and knowledge graph. An ontology defines types; a knowledge graph records instances. The ontology says “there is a class of object called Customer, and it can enter into a Places-Order relation with an Order”. The graph says “Huawei placed this order on 4 March”. One should be relatively stable, the other changes daily. “We built a knowledge graph” usually means someone accumulated a pile of facts — it does not mean anyone defined how those facts should be interpreted.

Ontology versus schema is subtler. The same customer row is a buyer in the sales system, a supplier in procurement, and a contracting party in the contract system. A schema can store that field; it cannot store the distinction. And for an agent that is about to act on your behalf, that distinction is the difference between who you pay and who pays you.

Twenty quiet years — so why now?

None of this is new. OWL 2 became a W3C Recommendation in 2009, with a second edition in 2012; RDF, Protégé and the whole Semantic Web stack have been complete for well over a decade. Mainstream enterprise software never really adopted any of it.

I don’t think the reason was technical. The consumer of an ontology used to be a human being, and humans have one capability models lack: when they hit a semantic gap, they stop and ask. A field called status — a person wonders whether that is order status or approval status, and goes to read the code or ask a colleague. Incomplete relations, broken inference chains: common sense papers over them. So rigorous semantics offered humans limited upside at very real cost, and for twenty years ontologies stayed in the assistive-tooling category.

LLMs invert exactly that property. Ambiguity is friction for a human and a degree of freedom for a probabilistic model. An LLM that meets status does not stop. It picks the most plausible reading, continues reasoning, and does so with complete confidence and no trace. You do not get an error. You get a very reasonable-looking wrong conclusion.

So the user changed. An ontology went from “helping people understand data” to “removing degrees of freedom from a model”. That, rather than any technical breakthrough, is why it resurfaced: there is finally a consumer willing to pay for strict semantics.

The real dividing line: descriptive versus executable ontologies

That said, equating today’s enterprise ontologies with 2009-vintage OWL is its own misreading. The two generations aim at different things.

Semantic Web ontologies are built for inference and consistency checking: subclass relations, equivalences, constraint conflicts. Such an ontology can tell you A is a kind of B. It cannot tell you whether this order may be rescheduled right now. What it produces is a descriptive ontology — in essence, a very rigorous document.

The template everyone cites today is Palantir Foundry. Per its public documentation, the ontology is split into two halves: semantic elements (object types, properties, links) and kinetic elements (action types, functions, dynamic security). Which is to say: actions and permissions are first-class citizens of the ontology, not application logic bolted on top of it.

That, and not modelling fidelity, is where the line falls:

An ontology that can only answer “what is an order” is a document. One that can answer “who, in which state, may reschedule this order, where the change is written back, and what trace it leaves” is part of the runtime.

Which connects straight back to my third takeaway from the Glean piece: the bottleneck for agents in production has moved from capability to authorisation. And every input an authorisation decision needs — what object is this, what action is this, who is permitted, where does the write land, who is accountable — sits neither in the model weights nor in a vector store. It has to be written down somewhere explicitly, and that somewhere is the ontology.

Where I disagree: don’t build a global ontology top-down

There is a seductive story going around: an enterprise should first build one unified model of its business world, describing the whole company. It sounds right, and I think projects started that way will mostly die in precisely the same place they died twenty years ago.

Master data management and enterprise-wide data models both tried global unification. They rarely failed on modelling technique; they failed because the model had no consumer. A model that no person and no program invokes daily will drift away from reality — and once it has drifted it stops being an asset and becomes a liability, because it is still there, still looks authoritative, and is now wrong.

This is already received wisdom in MBSE. It took systems engineering years to accept that a model’s value lies not in how completely it covers the system but in whether it sits on the delivery path. A model off that path is a one-shot document, however beautiful, and it starts rotting the moment the review ends. Enterprise ontologies are the same trap with a fresh set of people walking into it, and I see no reason this round will differ.

So my approach is to derive the ontology backwards from actions: decide first which actions an agent is allowed to perform, then work back to the objects, states, preconditions and permissions those actions require — and model only that. A minimum viable entry looks roughly like this:

Action: reschedule_order
  object:        Order (identity taken from the ERP order_no)
  precondition:  confirmed AND not yet shipped
  constraint:    new date must not exceed the contractual SLA;
                 a slip beyond 3 days requires manager approval
  permission:    the account owner, or the regional sales manager
  write-back:    ERP delivery-date field + change trace (who, on what grounds)
  provenance:    SLA from the contract system, permissions from HR reporting lines

Not one line of that is something an LLM could derive on its own; all of it is private to the company. And its size does not scale with how many tables you have — it scales with how many things you let an agent do.

The scope of an ontology should be set by the scope of authorisation, not by a data-asset inventory. That is the claim I hold most confidently right now, and the direction I am converging on in my own agent runtime: however solid the runtime is, if it cannot answer “should this action be allowed”, it is unusable inside a company — and that answer is not something the runtime gets to invent for itself.

The real cost is governance, not modelling

Judged on modelling alone, an ontology project looks cheap: how hard can a few dozen object types be? The cost is in three things that follow, none of them technical.

One: entity resolution, the dirtiest job. Huawei / HUA001 / 华为技术有限公司 / Huawei Technologies are one object. There is no elegant solution — rules, human review, endless maintenance. It belongs to the same family as Glean’s connectors: grinding work, which makes it both a moat and the best available excuse to postpone. Skip it and you have laid unified semantics on top of four mutually contradictory identifier spaces.

Two: semantic ownership. Who is allowed to change the definition of “strategic account”? Who signs off first? Without an ontology the question does not exist, because every system interprets it privately and departmental walls absorb the conflict. Unify it and the definition becomes a shared asset that needs an owner. This is the step that stalls most ontology projects — not the modelling tools. Where the technical preconditions are met and the organisational ones are not, whatever gets built goes unmaintained.

Three: semantic drift, the failure mode that worries me most. Change one definition and every agent depending on it changes behaviour simultaneously — without raising an error. They simply start making slightly different decisions. No stack trace, no alert; just metrics quietly deforming. So an ontology has to be run like a public API: versions, deprecation windows, change review, and every edit traceable to a person and a reason.

When you should not build one

Stated in reverse it is more useful. I would not do it when:

  • You only do Q&A and document retrieval, with no write operations. RAG is enough; the payoff will not cover the governance cost.
  • Business rules already live in one or two systems and there is no cross-system semantic conflict — the problem unified semantics solves does not exist here.
  • Nobody in the organisation can rule on definitions. The critical one. You can build it, but nobody will maintain it, and in two years it is a legacy asset no one dares delete or trust.
  • Data quality is too poor for entity resolution. Fix master data first. An ontology built on wrong identifiers amplifies the errors and lends them authority.

The signal that it is worth doing is sharp: you already have agents or automation writing across systems, and it has already changed something it should not have, at least once. After that first incident the discussion is no longer whether to build one, but at what granularity.

What I haven’t worked out

  • Whether the two-layer split holds. One view is that ontologies will separate into a canonical enterprise layer (slow-moving, governed like a product) and an ephemeral task-local layer built on the fly during agent planning. I lean towards agreeing, but I cannot see who reviews the ephemeral output or whether it should be persisted at all — not persisting means guessing again every time; persisting means expanding shared semantics with no governance.
  • Whether LLMs can extract an ontology themselves. Generating candidate types from documents and table structures is already technically feasible and very tempting. But the valuable part — who is allowed to do what, when two-person review is mandatory — is exactly the part not written in any document. Extraction gives you a skeleton, not a judgement, and the judgement is the part that hurts.
  • Whether ontologies and MCP tool definitions converge. A well-written tool definition (name, parameters, preconditions, side effects, permissions) is already an impoverished ontology entry. If tool definitions keep getting richer, the difference starts to look like two serialisations of the same thing. I run into this daily while writing the runtime and have no conclusion yet.

In short

The previous piece concluded that the model is not the moat; permissions and context are. This one goes a layer deeper: permissions and context themselves have to be written down explicitly somewhere, and that somewhere is the ontology.

But it should not be treated as three years of foundational engineering to be finished before anything is used. An LLM decides whether AI can understand what you said; an ontology decides whether AI can be trusted to touch a live order — and the only part of the world you need to define is the part the AI is allowed to touch.

References

Factual content comes from the public sources below; the judgements are mine.