Ontology – the word that sounds harder than it needs to be

Last time, the philosopher left us with ink on his shirt and a promise: ontology, the word that sounds harder than it needs to be. Time to make good on that promise.

Fair warning: the word will still sound a bit pretentious the first time you say it out loud. But the concept behind it is actually quite simple – and it turns out to be exactly what decides whether an AI system works, or breaks in the most confusing way possible.

What actually exists?

Ontology comes from the Greek ontos (being) and logia (the study of) – literally "the study of what is." Aristotle did not use the term ontology, but he spent a fair chunk of his career on closely related questions: what exists, what kinds of things exist, and how do we categorize them? It sounded philosophically deep in his time. It still sounds philosophically deep. But it also happens to be a question every organization and data system must deal with – and one that becomes hard to avoid when an AI is expected to work with business information.

An ontology is, in short, a map of which things exist in a given world, what they're called, and how they relate to one another. Not a dictionary (that was semantics' job – what the words mean). An ontology is the structure behind meaning: which categories exist, what properties they have, and what rules govern the relationships between them.

Remember "book the table" from the previous article? There, context helped us understand what the words meant. Through the lens of ontology, we can describe something more: what kinds of things exist in the restaurant's world and in the workshop's world, and what can be done with them. The restaurant has bookable tables, times, and guests. The workshop has workpieces, tools, and operations. The same words can point towards very different maps of what exists.

From philosophical question to technical blueprint

Here's the small twist that makes ontology relevant beyond philosophy seminars: when we build AI systems that must understand and act within a business, we need some way to represent which things exist and how they relate. Sometimes we do that with an explicit ontology. Sometimes the same assumptions are hidden in database schemas, APIs, documents, and people's heads. The question "what exists, and how does it relate?" suddenly becomes a technical question, not just a philosophical one.

Take a single word: customer. In the sales system, a customer is someone with a company ID and a sales stage. In the support system, a customer is someone with a ticket history and an SLA. In the finance system, a customer is a counterparty with payment terms. Three perfectly legitimate definitions – and if an AI agent is meant to act across all three systems at once, without a shared ontology stating "this is the same 'customer,' and here's how the concepts relate," it will sooner or later do something confusing. Not because it's dumb, but because it inherited three incompatible maps and was asked to navigate with all three at once.

That's why ontology work now shows up in contexts that sound considerably drier than Aristotle: knowledge graphs, data catalogs, information models, and governance platforms. A shared ontology can also give a control plane better information for its decisions. A control plane is the system's control room: the layer that determines what an AI agent may access, which actions it may perform, when it may perform them, and which rules it must follow. The ontology describes which things the agent is working with and how they relate. But the boundary of what the agent is actually allowed to do must still be enforced through permissions, policies, validation, and other technical guardrails.

The philosopher would probably smirk at the idea that his question about "the nature of being" can now help a system understand which invoice an AI agent is trying to send. The lawyer and the security officer, however, still get to decide whether it may send it.

When the ontology is missing

The funny (read: painful) part is that you rarely notice an ontology is missing until something has already gone wrong.

The classic case: an AI agent is asked to "update the customer's address everywhere." Without a shared model, it doesn't know whether "the customer's address" in the CRM is the same thing as "delivery address" in the warehouse system or "billing address" in the finance system. A badly designed agent guesses – just like it guessed at "short and funny" in the previous article – and may update the wrong field. A better agent stops and asks which address you mean. But to ask that question, the system must first know that a delivery address and a billing address are different things.

The language was understandable on the surface, but the concept was not precise enough. "The address" could refer to several different things, and the organization lacked a shared map of what an address is as a type of thing and how those different address concepts relate.

Put simply, that's the difference between semantics and ontology in a nutshell: semantics asks "what does this expression mean?" Ontology asks "what kinds of things and relationships make up the world we're talking about?"

The philosopher draws a map

Picture the philosopher with his quill pen again, except this time he's swapped the paper for a large map he's busy drawing. He marks out islands ("Customer"), bridges between them ("a Customer can have several Addresses"), and strict borders ("an Invoice belongs to exactly one Customer, never zero, never several"). That's fundamentally what an ontology is – a map, not of the terrain itself, but of which types of places exist and how one may legitimately travel between them.

And just like with real maps: a bad map can be worse than no map at all, because it provides false confidence. An AI system acting on an incomplete ontology may sound confident – it does, after all, have a map – even when that map is missing half the islands.

On the philosopher's map

• Customer is a type of thing.

• Ada Ltd is an actual customer.

• Delivery address is a type of address.

• Ada Ltd has a delivery address.

• An invoice must belong to exactly one customer.

What to actually do about it

The good news is that ontology work doesn't require a philosophy doctorate. Nor does ontology solve all of this on its own. But it gives us a shared language for tackling the problems alongside information ownership, data governance, permissions, and business rules.

In practice, it comes down to answering fairly concrete questions before letting an AI agent loose on real systems:

• Which "things" (entities) are we actually talking about – customers, products, cases, contracts?
• Which properties belong to each thing, and which are mandatory?
• How do the things relate – can a customer have several orders, and can an order belong to several customers?
• Where does "the truth" about each thing live when multiple systems each have their own version of it?
• Which actions are permitted in which context – and who or what decides that?

The first three questions sit squarely within ontology work. The question of where truth lives also belongs to master data, information ownership, and data governance. The question of permitted actions belongs to policy, authorization, and security architecture. Together they build the foundation for a control plane that actually holds.

Leave those questions unanswered, and a badly designed AI agent may fill the gaps itself – one guess at a time, until something breaks in a way that's hard to trace back to a single line of code.

The philosopher gets the last word, again

So: ontology. It still sounds a bit like something you'd discuss over red wine and existential dread late on a Friday night. But at its core, it's simply a question every organization should already have asked itself, AI or not: what exists here, what do we call it, and how does it all fit together?

The philosopher has put down his pen for now. The map is finished – or at least finished enough to navigate by. But a map, however good, still says nothing about what context you're actually standing in right now, or which question you should even be asking to move forward.

Time to talk about context.

Want to go deeper: W.V.O. Quine's On What There Is is a modern philosophical classic on what it means to say that something "exists." Tom Gruber's definition of ontology as "an explicit specification of a conceptualization" in A Translation Approach to Portable Ontology Specifications helped establish ontology as a technical concept in AI and knowledge representation. And for those who want to see ontology in its full, practical breadth, there's Barry Smith's introduction Ontology.

Next part

A good map still says nothing about where you're actually standing on it right now – that's context's job. Next time we talk about why context has become so critical that context engineering is one of the AI world's new favourite expressions, and why the best route there rarely comes down to having the right answer but asking the right question. We'll turn to Hal Gregersen and his book Questions Are the Answer to work that out.