Engramic Concepts
What is a knowledge graph, and what is it for in AI?
A knowledge graph is a way of storing information as entities and the relationships between them, rather than as documents or rows in a table. Instead of a paragraph mentioning that a supplier is tied to a contract that governs a product line, a knowledge graph holds supplier, contract, and product as distinct things with named links between them, so the connections can be followed directly rather than inferred from prose.
That much is settled and decades old. What is not settled is what a knowledge graph is _for_ once AI agents are involved — and on that question the term has quietly come to mean one specific thing, while leaving out another. In 2026 "knowledge graph" is used for two structures that solve genuinely different problems, and because they share a name they get treated as one. This page covers the established meaning, which is worth understanding, and then the distinction underneath it that the established meaning tends to hide.
What the Term Has come to Mean in 2026
Ask what a knowledge graph is for in AI today and you will mostly get one answer: better retrieval. The dominant pattern is GraphRAG — building a graph so an agent can traverse relationships that flat document search would miss.
The mechanism is worth stating briefly, because it is genuinely useful. Ordinary retrieval finds documents similar to a query, which struggles when the answer is spread across several documents connected only by a chain of relationships — how an account links to a sanctioned entity through three intermediaries, which contracts a supplier disruption touches. A knowledge graph encodes those relationships explicitly, so the system can follow the chain rather than hope the relevant hops happen to sit in similar-looking text. The published gains are real: graph-grounded retrieval has been measured improving precision on multi-hop questions substantially over vector search alone. This is now a mature category, with established graph databases, a growing vendor ecosystem, and a clear, well-evidenced job: making an agent's retrieval more complete and more accurate.
Hold onto one feature of this, because the rest of the page turns on it. In the GraphRAG pattern, the graph is built from content. An extraction process reads documents, pulls out the entities and relationships it can find, and assembles them into a graph. The graph is a derived structure: a map of what was in the source material, generated by a model reading that material.
The Distinction the Dominant Meaning Hides
There are two quite different things a knowledge graph can be, and the difference is not about the data structure — both are entities and relationships. The difference is where the contents come from.
One kind is extracted. Its contents are pulled out of existing documents by a process that reads them, the way GraphRAG builds its graph. It is a representation of what your source material says, and it is excellent for retrieval, because retrieval is precisely the task of getting back what your material already contains.
The other kind is curated. Its contents are put there on purpose, by people deciding what matters and what the organisation will treat as settled: this is our goal, this is the constraint we operate under, this is the decision we made and why, this is how things are done here. Nobody extracted these from a document, because mostly they were never written in one. They are authored directly into the graph as deliberate statements of organisational knowledge.
These are not competing implementations of the same idea. They answer different questions. An extracted graph answers "what do our documents say, and how is it connected?" A curated graph answers "what has this organisation actually committed to?" The first is a retrieval problem. The second is a governance problem. A graph built to make search better is not, by virtue of being a graph, also a record of what an organisation has deliberately established — and assuming it is, because both are called knowledge graphs, is the confusion this page exists to flag.
Why the Difference Matters for an Agent
For an agent about to act, the two kinds of graph play different roles, and conflating them produces a specific failure.
An extracted, retrieval-oriented graph improves what an agent can find. Asked a question, the agent traverses the graph and returns a better-grounded answer than flat search would give. This is real value, and for question-answering it may be all you need.
But an agent doing organisational work does not only need to find what the documents say. It needs to act from what the organisation has decided — including the things no document records: the constraint that lives in a manager's head, the decision whose rationale was never minuted, the standard everyone follows and no one wrote down. An extracted graph cannot contain these, because there was nothing to extract them from. A graph that only ever reflects existing content will faithfully reproduce the organisation's blind spots, because it can only know what was already written somewhere.
This is the same distinction that separates retrieving context from governing it. Retrieval gets back what exists. Curation establishes what should be treated as settled. An agent grounded only in the first is well-read; an agent grounded in the second is actually operating from the organisation's intent. The strongest setups use both — extracted graphs to make retrieval complete, curated knowledge to make the agent's understanding correct — but only if their difference is kept clear rather than collapsed into a single word.