How connected facts and agreed meaning fix the Five Agent Failure Patterns stopping AI agents reaching production – and the mistake most teams make on the way.
In Part 1 of this series, I described the Five Agent Failure Patterns that stop AI agents reaching production: meaning drift, the fragmented view, invented relationships, rules in the prompt and no memory of why. They share a single cause. The agent is being asked to act on an organisation that has never been described in a form it can use.
The usual response is to give the agent more to read. First more instructions in the prompt, then documents and data through retrieval, often called RAG. Both help. In my view, neither is enough. RAG gives the agent text, but it does not connect that text to its meaning, so the agent still has to decide for itself what things mean – the ontology is missing. RAG also holds no connections between facts, so the agent cannot follow the relationships in the data.
A knowledge graph stores an organisation's data as connected facts. Each fact links two things through a named relationship: this supplier provides this service, this customer holds this contract, this contract is governed by this policy. Put enough of those facts together and the graph becomes a map of how the organisation actually works.
For an AI agent, the difference is significant. Without an ontology and knowledge graph, data retrieval using agents probabilistically finds text that looks similar to the question, whereas a knowledge graph lets the agent deterministically follow the connections to the answer. Ask which suppliers in Asia depend on a cloud provider that had an outage this month, and a knowledge graph follows the detailed links between facts and returns a more accurate answer, along with the audit trail it used to get there.
Five connected facts. An agent can follow them in order and show its working – no similarity search and no guessing.
Once teams discover knowledge graphs, the natural next step is to load data into one. Customers from the CRM, accounts from billing, tickets from support – all into the graph, as fast as possible.
However this recreates the original problem in a new place. If the CRM's idea of an "active customer" and billing's idea of an "active customer" are both loaded without anyone agreeing what the term means, the graph now holds both meanings side by side. The duplicate customers are still duplicates. The agent can move through the graph faster, but it is moving through the same confusion. This is why organisations need an ontology.
A knowledge graph without an ontology is a faster version of the confusion an organisation already has about shared meanings.
An ontology is the agreed meaning behind an organisation. It defines the things an organisation cares about – customers, contracts, services, policies – how they relate to one another, and the rules they must follow. It is written in a formal standard (OWL, from the W3C), so machines can read it as precisely as people can.
A simple way to think about it: the knowledge graph holds the factual data, and the ontology is the dictionary and rulebook that says what those facts mean. It defines that a customer is a single legal entity, that "active" means one specific thing, and that every contract is governed by exactly one policy. Data from each IT system is then mapped to those definitions as it enters the graph.
Ontologies rarely need to be built from scratch. Most regulated industries already have well-established models – FIBO in financial services, FHIR in health – that can be adapted rather than invented. However that adaptation and design needs to be done by expert ontology engineers. A poorly designed ontology will not improve agent accuracy – instead it gives the agent a different set of mistakes.
A knowledge graph and an ontology give an agent the right facts and the right meaning. On their own, they do not make the agent use them. That is the job of an agent harness – a governance layer that sits around the agent. The harness supplies the ontology and the connected knowledge the agent needs for each task, checks every action the agent proposes against the organisation's rules before it runs, and records why each decision was made. The agent still does the reasoning. However it works from what the organisation has defined rather than from a guess, which greatly reduces hallucinations.
| Failure pattern | What fixes it |
|---|---|
| Meaning drift | The ontology defines each term once, and every system's data is mapped to that definition |
| Fragmented view | The graph links records from different systems that refer to the same thing |
| Invented relationships | Relationships are looked up in the graph, not inferred from what is statistically likely |
| Rules in the prompt | Rules sit alongside the ontology as constraints that can be tested and shared by every agent |
| No memory of why | Every answer traces back to the facts and definitions it used |
None of this replaces the LLM. The agent still reasons, plans and writes the answer. What changes is what the agent reasons over – connected facts with agreed meaning, rather than fragments of text and a best guess.
Agents that act on real business decisions do. A knowledge graph gives an agent connected facts about the organisation, so it can follow relationships to an answer and show its working instead of guessing.
The knowledge graph holds the facts. The ontology is the dictionary and rulebook that defines what those facts mean, how things relate and which rules they must follow.
They do different jobs. Retrieval (RAG) finds text that looks similar to a question. A knowledge graph answers questions that need several connected facts, and traces each answer back to its sources.
Rarely. Most regulated industries have established models, such as FIBO in financial services and FHIR in health, that can be adapted rather than invented. The adaptation does need expert ontology engineers, because a poorly designed ontology will not improve agent accuracy.