"Prepare the next best action for Customer X." A simple request to an AI assistant. What happens with it depends on what the system knows about the business.
Without business context, the language model searches CRM notes and the most recent records. It finds text, summarises it, and suggests something that sounds plausible. With an ontology, the system knows that Customer X is part of a group, that two opportunities are open, that a quote has gone unanswered for three weeks, that an invoice is overdue, that a service case has been escalated, and who in the company is responsible for this account. It can reason about the situation instead of merely retrieving text.
Most companies do not have a data problem. They have a context problem. AI can access records, documents and APIs. But it does not automatically understand what those things mean inside the business. That is precisely the gap an ontology closes.
The Problem Is Not Access, but Meaning
Over the past years, many companies have invested heavily in data access. APIs were built, integration platforms introduced, data lakes and lakehouses filled. A language model can now reach almost everything that exists digitally in the company. That is the foundation, but not the solution.
A record in the CRM is called an "account". A record in the ERP is called a "debtor". A record in the ticketing system is called an "organisation". In many cases, all three refer to the same customer. In some cases, they do not. The status "open" means something different in sales than it does in service. A "project" is a container for tasks in the project tool, a cost object in finance, and a won deal in sales.
People know these differences because they know the business. A model does not. It sees fields, tables and text. If nobody tells it how these things relate, it guesses. And in many cases, it guesses convincingly wrong. How quickly an agent ends up with the wrong customer as a result is something we have described separately.
What an Ontology Is, and What It Is Not
The term sounds academic. The matter is practical. An ontology is an explicit description of the things that matter in the business, their relationships to each other, and the rules that apply to them. It answers questions that people in the company answer intuitively, but a system cannot.
| Layer | Question answered | Example |
|---|---|---|
| Business objects | Which things exist, and what do they mean? | Customer, group, opportunity, quote, order, invoice, service case, employee |
| Relationships | How do these things relate? | A customer belongs to a group. A quote belongs to an opportunity. A service case concerns an order. |
| States and rules | What applies in which situation? | An invoice is overdue once the payment term has passed. A quote with no response after 14 days counts as at risk. |
| Permissions and actions | Who may see and do what? | A sales rep sees their own customer's terms, not everyone's. A discount above ten percent needs approval. |
| Provenance | Where does the truth for each object live? | Addresses come from the ERP, contacts from the CRM, tickets from the service system. |
What an ontology is not: it is not another data warehouse, not a data catalogue, and not a replacement for the integration platform. It does not copy data. It describes what the data in the existing systems means and how it fits together. The data stays where it is. The meaning becomes explicit.
Integration Connects Systems. Ontology Connects Meaning.
A classic integration ensures that a new customer from the CRM is created in the ERP, that invoices flow back into the CRM, and that a ticket carries the customer number. That is necessary and valuable. But it only answers the question of how data gets from A to B. It does not answer the question of what a customer is.
For people, that is enough, because they bring the meaning with them. For an AI system, it is not. If an agent is supposed to answer the question "Which customers are at risk?", it needs a definition of "at risk" that holds across systems. That definition does not exist in any of the systems. If it exists at all, it lives in employees' heads or in a process document nobody reads any more.
Traditional integration connects systems. An ontology connects meaning. Together, they make enterprise data usable for AI.
The ontology is thus the layer that sits above integration. Integration delivers the data. The ontology says what it means and how it assembles into a picture. Without integration, the ontology has nothing to describe. Without the ontology, the AI does not know what to do with what is described.
Why Agents Need This Layer
With a chatbot that answers questions about documents, missing context is barely noticeable. The system finds relevant passages and formulates an answer. With an agent that is supposed to act in the business, missing context becomes a risk.
An agent has to decide which tool to call, with which parameters, in which order, and when to stop. To do that, it has to understand the situation it is in. "Customer has an overdue invoice and an escalated service case" is a different situation from "customer has an open opportunity and an unanswered quote". In the first case, a sales call is inappropriate. In the second, it is overdue. An agent that only sees records cannot tell the difference. An agent that knows the ontology can.
The ontology also gives the agent the boundaries of its actions. Which actions exist at all? Which of them are allowed in this state? Which require approval? Writing this information into the prompt works for an agent with three tools. For a company with thirty agents accessing the same systems, it takes a shared layer that describes these rules once and makes them binding for all. The step from RAG to agentic RAG is exactly this transition from retrieving to acting, and it only works with context.
How an Ontology Is Built: Not as a Big-Bang Project
The most common reason ontology initiatives fail is the ambition to model the entire company at once. That takes years, and by the end, the model no longer matches the business. The better route is the reverse: start with one process and the objects that process needs.
| Step | What happens | Result |
|---|---|---|
| Select a process | One concrete use case, such as customer care in key account management | A clear scope, usually ten to twenty objects |
| Name objects and relationships | Business and IT jointly define what a customer, a quote, a case is and how they relate | A shared vocabulary both sides own |
| Assign sources | For each object, it is decided which system holds the truth | No duplicate definitions, clear provenance |
| Add rules and states | What does "at risk", "overdue", "strategic" mean? | Terms agents can evaluate |
| Map permissions | Who may see which objects and trigger which actions? | The basis for secure agent access |
| Test with the first agent | The agent works against the ontology, not against raw tables | Visible where the model still has gaps |
The first process produces a core that grows with every further use case. The objects "customer" and "order" are reused in the second process, not reinvented. After three or four processes, the ontology covers a large share of what agents in the company need. And it stays current, because it is tied to real use cases.
The division of roles matters. The ontology does not belong to IT alone. What a strategic customer is, sales decides. When a case counts as escalated, service decides. IT ensures these definitions are technically represented and connected to the source systems. An ontology maintained by only one side loses touch either with the business or with the technology.
Where the Ontology Lives in the Architecture
Technically, an ontology is a semantic layer that sits between the enterprise systems and the AI components. It reaches the source systems through the integration platform and provides agents with a unified view: objects instead of tables, relationships instead of foreign keys, states instead of status codes.
There are several ways to implement it, from graph databases and semantic layers on a data platform to a collection of well-described APIs that deliver objects and their relationships. Which route fits depends on the existing landscape. Anyone already running an API-led integration architecture can build the ontology as a layer on top. Anyone using open table formats as an integration layer can anchor the semantic definitions there.
Less important than the technology are three properties. First: the ontology is machine-readable, so agents can use it at runtime rather than having someone transcribe it into prompts. Second: it is reachable for agents through standardised interfaces, for instance as tools with clear descriptions, as MCP for enterprise APIs envisages. Third: it carries permissions along, so an agent knows not only what an object is, but also whether it may see it in the current context.
What does not work is the attempt to deliver context through the prompt alone. A system prompt with twenty pages of explanations about the company is expensive, slow, hard to maintain, and not reliably followed by the model. Context belongs in the architecture, not in the text.
What Should Be Settled Before Starting
Before a company starts on an ontology, it is worth answering these questions:
| Area | Guiding question |
|---|---|
| Use case | Which process should benefit from context first, and which decision should an agent make better there? |
| Objects | Which ten to twenty things does this process need, and what are they called in the various systems? |
| Truth | Which system is authoritative for which object, and where are there contradictions today? |
| Rules | Which terms the business uses every day have no formal definition? |
| Ownership | Who maintains the definitions on the business side, and who implements them technically? |
| Access | How do agents reach the ontology, and how are permissions enforced in the process? |
| Growth | How are new objects and processes added without breaking what exists? |
The answers do not have to be perfect. They have to be good enough to start with the first process. Everything else follows from use.
Conclusion
The discussion about enterprise AI often revolves around models: which is the best, which the cheapest, which may run in the company's own data centre? These questions are legitimate. But they obscure what most initiatives actually fail on. Not the model, but the fact that the model does not understand the business. That clean data matters more than the best model is something we have already shown. Context is the next step after clean data.
An ontology is the layer that translates data into meaning. It turns tables into business objects, foreign keys into relationships, and status codes into situations an agent can reason about. It is not built in a big-bang project, but process by process, carried jointly by business and IT.
Your AI does not need more data. It probably already has more than it can process. It needs context. And context is not a question of the model, but of the architecture.