TL;DR: A context graph is a graph that records entities, the decisions made about them, and when and why each decision happened, so an AI agent can retrieve precedent instead of guessing. The term has two working definitions in 2026: a structure for what goes into an LLM’s context window, and a persistent record of organizational decisions. They describe the same data at two time scales.
A context graph is a graph that stores the relationships, timing, and reasoning around facts so an AI system can pull the right context for a decision. Nodes hold entities, events, policies, and decisions. Edges record how they connect, which rule applied, who approved an exception, and when each fact was true.
Why does anyone need this? Because the systems agents read from were built to store state. Your billing database knows a customer got a refund outside the 30-day window. It has no record of why, or of who signed off. And it can’t tell whether that exception should apply to the next customer who asks. A human support lead carries that knowledge in their head. An agent doesn’t, so it either follows the written policy too literally or escalates everything.
Where did the term “context graph” come from?
The phrase took off with one essay. In late December 2025, Jaya Gupta and Ashu Garg of Foundation Capital published AI’s trillion-dollar opportunity: Context graphs. Their argument: the next generation of enterprise platforms won’t come from improving systems of record like CRMs and ERPs. It will come from capturing what those systems never stored, the decision traces that explain why an action was taken, under which exception, and with what precedent.
Their one-line diagnosis: “The reasoning connecting data to action was never treated as data in the first place.”
The term itself is older. A 2014 paper in Sensors used “context graphs” to describe situations in ambient assisted living systems, and graph-database teams had used similar language for years. What changed in 2025 was the framing: context graphs as the missing memory layer for AI agents.
Why do people define context graphs two different ways?
IBM’s definition is about the model. A context graph structures “discrete information in the context window of a large language model,” with nodes for pieces of information and edges for the relationships between them. The graph gets assembled per query: retrieve candidate nodes, expand along edges, rank, and serialize the winning subgraph into the prompt.
| Context-window definition | Decision-record definition | |
|---|---|---|
| Popularized by | IBM, GraphRAG-style retrieval | Foundation Capital, Thoughtworks Radar |
| Lifespan | One query | Months to years |
| Core unit | Chunk, entity, or fact | Decision event with conditions and precedent |
| Question it answers | “What should the model see right now?” | “How have we handled this before, and why?” |
These fit together once you stop treating them as rivals. The decision record is the store. The per-query subgraph is the view you load into the context window. IBM’s own explainer points at this when it notes that the graph “is not typically what the model directly consumes” and instead determines what the model should see at inference time.
So a working definition that covers both: a context graph is a persistent, time-aware graph of entities and decisions, plus the retrieval logic that selects a relevant slice of it for an agent at the moment of a decision. If a vendor’s version only has one half, ask what they do about the other.
What’s inside a context graph?
Start with a single decision, since that’s the unit everything else hangs off. Say a billing agent approves a refund outside the standard window because an outage overlapped the customer’s billing period. In a context graph, that decision becomes a node:
{
"id": "dec_8841",
"type": "Decision",
"action": "approve_refund_exception",
"subject": "account:acme-co",
"proposed_by": "agent:billing-assistant",
"approved_by": "person:j.ortiz",
"policy_applied": "policy:refunds-v7",
"exception": "refund requested 41 days after charge; policy limit is 30",
"reason": "Outage INC-2291 overlapped the billing period",
"valid_from": "2026-04-12",
"recorded_at": "2026-04-12T15:03:11Z",
"confidence": 0.92
}And then the edges that make it a graph rather than a log entry:
(dec_8841) -[:ABOUT]-> (account:acme-co)
(dec_8841) -[:APPLIED_POLICY]-> (policy:refunds-v7)
(dec_8841) -[:JUSTIFIED_BY]-> (incident:INC-2291)
(dec_8841) -[:APPROVED_BY]-> (person:j.ortiz)
(dec_8841) -[:PRECEDENT_FOR]-> (dec_9102)This example is illustrative, not a standard. There is no agreed schema for context graphs yet, and every team rolls its own. But the node types recur across nearly every published design:
- Entities: customers, accounts, services, people, documents. This layer is an ordinary knowledge graph.
- Events and decisions: what happened, what was decided, what was escalated or overridden.
- Policies: the written rule, versioned, so you can tell which version a decision ran under.
- Precedent links: edges from one decision to later decisions that relied on it.
Two attributes deserve more attention than they usually get.
Provenance. Every node should say where it came from: a human approval, an agent’s proposal, an import from a ticketing system. The W3C already standardized this vocabulary in 2013 as PROV-O, built on three core classes: Entity, Activity, and Agent. You don’t have to use RDF to borrow the model.
Two kinds of time. Look at the example again. It has both valid_from and recorded_at. That’s deliberate, and it’s the part most explainers skip. Martin Fowler’s writeup on bitemporal history separates actual time (when something was true in the world) from record time (when your system learned it). A context graph needs both, because the question an auditor asks after an agent makes a bad call is “what did the system know when it decided?” If you only store one timestamp, you can’t answer that once anything gets corrected retroactively.
Neo4j’s William Lyon, borrowing a framing from Subramanya N, calls this the difference between the “state clock” and the “event clock.” Databases were built to record what’s true now. Almost nothing records what happened, in what order, and with what reasoning. Bitemporal modeling is how you make the event clock queryable.
How is a context graph different from a knowledge graph, RAG, or an audit log?
Short version: a context graph is a knowledge graph with decisions and time added, queried through retrieval that looks a lot like RAG, and it keeps a record like an audit log does, except that record is linked and queryable.
| Knowledge graph | Vector RAG | Audit log | Context graph | |
|---|---|---|---|---|
| Answers | What exists and how it relates | What do our documents say about this? | What action happened, and when? | How have we decided cases like this, and why? |
| Core unit | Entity and relationship | Text chunk plus embedding | Timestamped event row | Decision linked to entities, policy, and precedent |
| Time | Usually current state only | Document dates, if any | Record time only | Valid time and record time |
| Retrieval | Graph query | Similarity search | Filter by time or actor | Similarity search to find entry points, then traversal |
| Without it, agents… | Confuse entities and hallucinate relationships | Lack the relevant facts | Can’t reconstruct what happened | Apply written policy too literally or over-escalate |
The audit log comparison matters most in practice, because many teams already have one and assume it covers this. It usually doesn’t. An audit log tells you that j.ortiz approved refund 8841 at 15:03. It doesn’t link that approval to the outage that justified it, the policy version it bent, or the eleven later refunds that cited it. Those links are the product.
How does an AI agent use a context graph at decision time?
The retrieval loop looks like this:
- Find entry points. Embed the incoming request and run a similarity search to get candidate nodes: the customer, the account, the product, and similar past decisions.
- Traverse. Expand from those nodes along typed edges, a few hops out. (Neo4j’s context graph demo traces causal chains up to five hops back.) This multi-hop step is what a flat vector search can’t do, since the relevant precedent is often connected to the request without being textually similar to it.
- Filter by time. Drop anything that wasn’t valid at the relevant moment. A precedent set under
refunds-v6shouldn’t govern a case underrefunds-v7. - Rank and trim. Score nodes by relevance, recency, provenance, and confidence, then cut to fit the token budget. Loading the whole neighborhood into the LLM context window wastes tokens and buries the signal.
- Serialize. Convert the selected subgraph into prompt text that states the relationships explicitly (“Decision 8841 approved an exception to refunds-v7, justified by INC-2291”).
- Write back. Record the agent’s new decision as a node, linked to the precedents it used.
Step 6 is where a context graph differs from ordinary retrieval. Each decision adds to the record, so the graph gets more useful the more work agentic AI systems do. That is also why step 6 is where most of the risk sits.
If steps 1 through 5 sound familiar, they overlap with GraphRAG, the graph-based retrieval approach Microsoft Research published in 2024. GraphRAG builds an entity graph from a document collection to answer questions across it. In the paper’s LLM-judged head-to-head tests, its global approaches beat conventional vector RAG on answer comprehensiveness 72-83% of the time on podcast transcripts and 72-80% on news articles, though vector RAG still produced the most direct answers. A context graph borrows the retrieval mechanics and adds decisions, policies, precedents, and time.
What are the security risks of a context graph?
Almost nothing written about context graphs so far treats them as an agentic AI security problem. That’s a gap, because a context graph gives agents authority: its contents tell an agent what it’s allowed to do. Here’s where I’d expect problems.
Precedent poisoning. One bad exception, once approved, gets retrieved as precedent for every similar case after it. An attacker doesn’t need database access. They need to get a single unusual request approved, through social engineering or a support rep having a bad day, and the graph amplifies it from there. This is data poisoning with a longer fuse. Mitigation: require a human approval or a verified outcome before a decision can become PRECEDENT_FOR anything.
Stored prompt injection. Look at the reason field in the example. It’s free text, written by a person or an agent, and step 5 pastes it into another agent’s prompt later. That is a textbook path for indirect prompt injection, which OWASP describes as an LLM accepting input from external sources that alters its behavior in unintended ways.
Treat every free-text field in the graph as untrusted input when you serialize it.
Traversal leaks. A graph built to answer “why” can connect things nobody meant to connect, the same property that makes a security graph useful for mapping attack paths. Two hops from a customer’s refund might reach an HR decision about the employee who approved it.
Access control has to apply to edges during traversal, not only to nodes at the start. If your permission model checks “can this agent read account:acme-co?” and stops there, it’s incomplete.
Agents writing their own precedent. When an agent’s decisions feed the graph that guides its next decisions, errors compound. Without a check, an agent that approves one borderline case can cite itself into a pattern. That’s agent drift with a paper trail. Separate “decisions recorded” from “decisions eligible as precedent,” and keep a human or an outcome signal on that gate. An agent control plane is a natural place to enforce it.
Aggregation privacy. Patterns mined from a handful of users are those users’ activity with the names removed. Glean’s engineering team, describing its own build, only treats a pattern as viable if it appears across at least k distinct users and n independent traces, dropping anything rarer to preserve anonymity. Pick your thresholds before you ship.
Stale precedent. Policies change. A precedent set under last year’s policy can look authoritative to an agent that doesn’t check valid time. This is the AI governance failure that bitemporal modeling exists to prevent, and it’s the one I’d test first.
None of these are reasons to skip context graphs. They’re reasons to design the write path with the same care as the read path. For the broader control set, see our guides on AI access control and AI agent guardrails.
When is a context graph worth building?
Not yet, for most teams. HubSpot co-founder and CTO Dharmesh Shah called the idea “elegant, intellectually compelling” and then offered a reality check: “We’re barely at the point where semi-autonomous agents are getting deployed for some key use cases.” Most companies, he wrote, are “still struggling with basic data unification.”
A context graph is worth building when these four things are true:
- Decisions in the workflow regularly involve exceptions that a human approves, such as refunds, discounts, access grants, or claims.
- An agent already sits in the execution path, so traces can be captured at decision time instead of reconstructed later.
- You can resolve identities across systems. If “ACME Inc” in the CRM and “Acme” in support are two different nodes, every pattern you mine is wrong.
- Someone owns the schema and will version it like a public API.
Skip it if the decisions are fully rules-based (a rules engine is cheaper), if you have no agents in production, or if you can’t capture the reason when the decision is made. A “why” reconstructed weeks later from Slack threads is a guess with a timestamp.
Frequently asked questions about context graphs
Is a context graph a type of knowledge graph?
Yes. IBM calls it “a form of knowledge graph,” and the Thoughtworks definition describes it as a knowledge representation technique. The difference is scope: a context graph adds decisions, policies, precedents, and time to the entity layer that a knowledge graph already provides.
What data sources feed a context graph?
Systems of record (CRM, ERP, billing, ticketing), communication tools where approvals happen, policy documents, and the agents’ own tool calls and outputs. The hard part is identity resolution across those sources rather than collecting the data.
What role does semantic search play in a context graph?
Semantic search finds the entry points. Embeddings locate the nodes most similar to the request, then graph traversal expands from there to reach connected precedent and policy that similarity alone would miss.
Do you need a graph database to build a context graph?
Not to start. Property graph databases such as Neo4j and RDF triple stores (through SPARQL property paths) make multi-hop traversal easy to express, which matters once causal chains get deep. For a first workflow, a well-designed relational schema with decision, policy, and precedent tables will tell you whether the idea pays off before you add infrastructure.
Is a context graph the same as GraphRAG?
No. GraphRAG is a retrieval technique that builds an entity graph from documents to answer questions across a corpus. A context graph can use GraphRAG-style retrieval, but it also stores decisions and their timing, which a document graph doesn’t capture.
Where to go from here if you’re evaluating context graphs
Read the two primary sources first: the Foundation Capital essay for the business argument and the Thoughtworks Radar entry for the engineering view. Then pick one exception-heavy workflow, log its decisions for a month using a schema like the one above, and run a simple agent evaluation: does an agent handed those records make better calls than one handed the policy document alone? That test costs a few days and tells you more than any vendor demo will.