What is a context graph?

A context graph is a connected record of what an agent needs to do a piece of work. It holds the things involved, what is true about them now and the decisions people and agents have already made about them, each with a source. The term is new and means slightly different things depending on who uses it. 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.

The difference from a knowledge graph is scope. A knowledge graph holds what exists in a domain and how it relates. A context graph adds the state, history and decisions around a particular piece of work.

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.

We have seen the same gap first-hand. At a planning-software company, a new head of sales changed the deal stages without telling the CFO. The CRM just showed the new stages, not that they had changed. An agent reading the CRM that week would have treated them as if they had always been there.

The why behind a decision is data. An agent that can see precedent makes better calls than one that sees only outcomes, so the case for context graphs is sound.

A trace needs something stable to attach to

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.

Getting that right comes before any decision is recorded. In a Belgian outreach build we started from about 4,437 companies in a public CO2 register. Matching on company name was unreliable, so the domain became the primary key. 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.

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.

An agent’s conclusion is not yet a fact

Agents will write most of the traces, because they are in the path of the work and can record why they acted. If every conclusion an agent writes becomes precedent for the next agent, 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.

Ask three questions before you build or buy one

If you are evaluating a context graph, the questions that matter are about the foundation under it.

• What does a trace attach to? If the answer is a record in one system, the same customer will have several histories. It should attach to one identity that every source resolves to.
• What happens when a fact changes? A new value should supersede the old one and keep it as history, with the time it was true and the time it was recorded. If facts are overwritten, precedent points at a world that no longer exists.
• Who promotes a conclusion into a fact? If nobody does, agents’ guesses become precedent. There should be a person or a rule, and the graph should show which facts passed through it.

Record the decisions. Build the world they are about first.