What is a context graph for AI agents?
A context graph for AI agents is a connected record of what one task needs: the things involved, their current state and the decisions behind them, sourced.
A context graph for AI agents is a connected record of what an agent needs to do one piece of work: the things involved, what is true about them now and the decisions already made about them, each with a source.
The term is new and used in a few ways. All of them agree that agents need connected facts rather than more text, and they are right. Less is said about what the decisions attach to. A record of decisions is only useful if the companies, people and policies it points at are stable, current things. That foundation is a world model for knowledge work, and a context graph is the working layer on top of it.
The term means three things, and they share one idea
IBM uses it for something small: a way of structuring information inside a language model’s context window, with nodes for pieces of information and edges for how they relate. Neo4j uses it for something larger: “a connected representation of the knowledge, state, history, and decision records an AI agent needs to complete a task”. Foundation Capital’s December 2025 essay brought the term into wide use, and it means something more specific still: “a living record of decision traces stitched across entities and time so precedent becomes searchable”.
These are three sizes of the same idea. An agent should not have to infer the state of a company from a pile of documents. It should be handed the relevant things, already connected, with the history that explains them. We argued the same from the other side in more context makes agents worse. Past a point, adding text degrades the agent. What it needs is the smallest view of the work that is still sufficient.
Context graph vs knowledge graph vs world model
The four terms describe layers of the same stack, and a context graph is the narrowest.
| Term | What it holds | Scope | How long it lives | The question it answers |
|---|---|---|---|---|
| Ontology | The kinds of things in a business, what each means, how they may relate and what can be done with them | The whole business | Changes when the business changes | What can exist here, and what can we do with it? |
| Knowledge graph | The particular companies, people, places and events, connected according to the ontology | A domain | As long as the domain is maintained | What exists, and how is it connected? |
| World model for knowledge work | The graph, plus the data that keeps it current, the knowledge attached to each thing, time and a source on every fact | The company and the world it works in | Maintained continuously; every job adds to it | What is true about our business and its world right now, and how do we know? |
| Context graph | The slice one task needs: the things involved, their current state and the decision traces behind them | One task | Assembled for each task; its decision traces are kept | What does this piece of work need, and what was decided before? |
The difference from a knowledge graph is scope and time. A knowledge graph holds what exists in a domain and how it relates. A context graph is cut to a task and adds state, history and the reasoning behind past decisions. The ontology decides which kinds of things and relationships it can contain. The world model is the maintained whole it is drawn from.
Decision traces are what systems of record never kept
Foundation Capital’s central point is about what a CRM leaves out. It records that a renewal closed at a discount. It does not record why the discount was allowed: the incidents that justified it, the escalation that forced it, the earlier exception a VP approved. That reasoning lives in Slack threads, calls and people’s heads, and it was never treated as data.
What a decision trace records
A decision trace is the record of one decision: what was decided, about which things, on what evidence, under which rule, by whom and when. It is what turns a context graph from a snapshot into precedent an agent can search. Using Foundation Capital’s renewal example below, a trace would hold this.
| Field | What it records | In the renewal example |
|---|---|---|
| Decision | What was decided | A 20% discount on the renewal |
| Subject | The things it is about, each as one identity | The customer, the contract and the discount policy |
| Evidence | What the decision rested on, with sources | Three SEV-1 incidents, an open escalation and an earlier exception |
| Rule | The policy applied, or the exception to it | A 10% cap, exceeded with approval |
| Decided by | A person, an agreed rule or an agent within its limits | The VP who approved the exception |
| When | The date, and which version of the policy was in force | The renewal date and the policy current then |
| Status | Proposed by an agent, or accepted as fact | Accepted, because a person approved it |
Without the subject field resolved to real identities, the rest is a note in a log. That is why the next sections start with identity.
An example from sales: a renewal and a meeting
Foundation Capital’s example is a renewal agent that proposes a 20% discount against a 10% policy cap. To justify it, the agent pulls three SEV-1 incidents from PagerDuty, an open escalation in Zendesk and a prior renewal thread where a VP approved a similar exception. That only works if the agent knows all of those are about the same customer and the same policy. It also has to know the earlier exception still counts as precedent.
Everyday sales work needs the same thing at a smaller scale. An agent preparing a rep for a call needs the account, the people attending and their current roles, the open deal and how its stage changed, the last few calls and the payment terms finance agreed last quarter. A context graph hands it exactly that, already connected. Without one, the agent searches the CRM, the inbox and Slack separately and has to guess that a company spelled three ways is one customer.
Getting that right comes before any decision is recorded. At a deep-tech company selling into hospitals, a partner spreadsheet of about 2,700 companies collapsed to 64 ranked accounts once the territory was modelled from government sources and linked to the CRM. Before that work, a decision trace would have attached to a string. The same customer in three systems would have been three customers, each with a third of its history.
Why does it matter for AI agents?
Identity is the first property a context graph needs. Current state is the second. A precedent set under last year’s policy only counts if that policy still holds, so the graph has to know which facts have been superseded and when. Provenance is the third. A discount a VP approved and a discount an agent inferred from a thread are different kinds of fact. These properties are what make a world model for knowledge work different from a database, and a context graph inherits them or goes without.
Agents will write most of the traces, since they are in the path of the work. If every conclusion an agent writes becomes precedent, the graph fills with guesses that look like history.
We keep interpretation separate from accepted truth. An agent’s finding attaches to the thing it is about, with its evidence. It becomes an accepted fact only when a person or an agreed rule promotes it. The daily account list at the deep-tech company shows the difference. Each run leaves a trace on the graph, so the next run starts where the last one stopped, and a company that has been on the list stays off it for 30 to 60 days. That trace records what the agent did. It makes no claim about what is true of the company.
How do you build a context graph?
We build them in this order, for one piece of work at a time.
| Step | What it involves |
|---|---|
| 1. Pick one piece of work | Start from a task with a clear owner and a standard, such as preparing a renewal or a planning round. |
| 2. Resolve identities | Make every source point at one record per customer, person, product and policy. |
| 3. Add time to every fact | Record when each fact became true and what it replaced, so the graph knows what is current. |
| 4. Record decisions as traces | Attach each decision to the identities it is about, with its evidence, rule and decider. |
| 5. Keep findings apart from facts | Store an agent’s conclusions as findings until a person or an agreed rule promotes them. |
| 6. Hand each task only its slice | Give the agent the things, state and traces this task needs, and nothing else. |
Steps 2 and 3 are the world model work. The rest is what makes it a context graph. For how this fits a full deployment, see how to deploy AI agents in an enterprise. The ontology underneath is covered in how to build an ontology for AI agents.
Questions people ask
Is a context graph the same as a knowledge graph?
No. A knowledge graph describes what exists and how it connects. A context graph is the part of that a task needs, plus current state, history and the decisions made about it.
Where does the term come from?
It has been used by IBM and Neo4j, among others. Foundation Capital’s December 2025 essay brought it into wide use, with the focus on decision traces: recording why something was decided, not only what.
Do you need a world model before a context graph?
You need what a world model provides: one identity per customer, person and policy, facts that record when they were true, and a source on each one. Without that, decision traces attach to strings, and the same customer ends up with several partial histories.
What should you ask before building or buying one?
Ask what a trace attaches to (it should be one identity that every source resolves to), what happens when a fact changes (the new value should supersede the old one and keep it as history) and who promotes an agent’s conclusion into a fact (there should be a person or an agreed rule, and the graph should show which facts passed through it). Record the decisions, but build the world they are about first.
What is a decision trace?
A record of one decision: what was decided, about which things, on what evidence, under which rule, by whom and when. Decision traces make past decisions searchable as precedent.
Is a context graph the same as agent memory?
They overlap. Agent memory is what one agent keeps between runs. A context graph is shared by agents and people, tied to the company’s identities, and keeps decisions with their sources. An agent’s memory can feed it, but only as findings until they are promoted.
