In brief: A context graph records why decisions were made, not just what the data says now: the inputs, the rule, the approver, the exception and the outcome, linked across cases. It gives AI agents precedent and gives auditors an answer. This guide covers what it contains, how it differs from a knowledge graph, GraphRAG and process mining, and how to start with one decision type.
Who this is for: CIOs, CDOs and heads of AI platforms deciding what their agents need beyond data, and the risk and audit teams who will have to explain what those agents did.
A context graph is a connected record of how decisions were made in a business: what was decided, on what information, under which rule, by whom or by which AI agent, with what exception or approval, and what happened afterwards. Where a database stores the final state ("payment terms: 90 days"), a context graph stores the reasoning that produced it ("90 days agreed by the finance director as an exception to the standard 30, because the supplier is the only source for a critical part").
The term gained wide use after the Foundation Capital essay by Jaya Gupta and Ashu Garg, AI's trillion-dollar opportunity: Context graphs (22 December 2025), which argued that the next generation of enterprise systems will be built on these decision records and not only on the data that today's systems of record hold.
Two meanings you will see
The term is used in two ways, and it helps to know which one a vendor means.
| Meaning | What the graph holds | Who uses it this way |
|---|---|---|
| Decision record (this guide) | Decisions, their reasons, rules, approvals and precedent, kept over time | Foundation Capital's essay; decision-infrastructure and governance platforms |
| Context-window structure | The pieces of information given to a model for one task and how they relate | IBM's explainer (May 2026) and some retrieval tools |
The two connect: a decision-record graph is one of the best sources for the small, well-structured context a model needs for each task.
Why systems of record are not enough
An ERP or CRM tells you what is true now. It rarely tells you why. The reasons live in email threads, chat messages, meeting calls and people's memory. A human employee fills that gap by asking a colleague. An AI agent cannot, so it either stops or guesses. A context graph puts the "why" where an agent can read it.
What a context graph contains
- Entities: the things decisions are about, such as customers, suppliers, invoices, assets and policies.
- Decisions: each one as its own record, with a time, an owner and an outcome.
- Inputs: the data the decision used, with where it came from.
- Rules: the policy or threshold that applied, and its version at that time.
- Exceptions and approvals: who allowed a departure from the rule, and the stated reason.
- Precedent links: connections to earlier decisions of the same kind.
- Time: when each fact and rule was valid, so the graph can answer "what was true on that date?" as well as "what is true now?"
A single decision captured this way is often called a decision trace. The graph is what you get when many traces are linked through the entities and rules they share.
How a context graph works
- Capture. When a person or agent makes a decision, the inputs, rule, approver and reason are recorded at that moment.
- Link. The record is connected to the real customer, order, policy and earlier decisions it relates to.
- Retrieve. When a new decision comes up, the agent pulls the small, relevant part of the graph: this customer, this rule, the last few similar cases.
- Check. Policy is applied to that context before the agent acts.
- Write back. The new decision becomes another trace, so the graph improves with every use.
inputs, rule, approver, reason
to the real customer, order, policy
this case, this rule, similar cases
policy before the agent acts
the new decision becomes a trace
Each decision feeds the next one: the loop is what makes the graph grow with use.
Context graph vs knowledge graph vs ontology
| Ontology | Knowledge graph | Context graph | |
|---|---|---|---|
| Describes | The types of things that exist and how they may relate | The actual things and how they relate | How and why decisions about those things were made |
| Typical statement | "A supplier provides parts" | "Supplier A provides Part X" | "Supplier A was approved over B despite a higher price, because of delivery record" |
| Changes when | The business model changes | Facts about the business change | A decision is made |
| Main use | Shared vocabulary | Search, lookup, grounding answers | Precedent, audit, governing agent actions |
The three work together. The ontology gives the vocabulary, the knowledge graph tells an agent what exists, and the context graph tells it what has been done before in this situation and what it is allowed to do now.
Context graph vs GraphRAG
GraphRAG, from Microsoft Research, is a retrieval technique: it uses a graph of documents and entities to find better passages for a model to read. A context graph is a record of decisions. GraphRAG improves what an agent knows; a context graph adds what was decided, under which rule, and with whose authority. An agent can use both, and GraphRAG-style retrieval is one good way to query a context graph.
An example
An agent is asked to approve a supplier invoice that is 4% over the purchase order. The system of record shows the invoice, the order and a 2% tolerance. On that alone the agent must reject or escalate. The context graph adds that the same supplier's last three overages were approved by the procurement head under a freight-surcharge exception, and that the exception expired last month. Now the agent can make the right call: escalate, and say exactly why.
Why AI agents need a context graph
- Memory across sessions. A model starts each task with no memory. The graph carries what was decided last time.
- Consistency. Similar cases are handled the same way because the precedent is visible.
- Fewer wrong guesses. The agent reads the reason for an exception and does not have to invent one.
- Smaller prompts. A few linked facts replace pages of raw documents, which also reduces context rot.
- Audit. Every agent action can be explained from the record.
How to build a context graph: one decision first
The teams that get value fastest do not model the whole business. They start with one decision type and grow from there.
- Start with one decision type. Pick a frequent, costly one, such as invoice exceptions, discount approvals or access requests.
- Capture at the moment of decision. Record inputs, rule, approver and reason when the decision happens. Reconstructing it later from logs loses the reason.
- Link to the systems of record. Each trace should point to the real customer, order or policy record, not to a copy.
- Version the rules. Store which version of a policy applied, so old decisions are judged by the rule of their day.
- Make agents write as well as read. Every action an agent takes should add a trace, so the graph grows with use.
- Govern access. Decision records are sensitive. Apply the same permissions to the graph as to the underlying data.
Map your first context graph. In a one-day context graph workshop we pick one decision type with you, list the inputs, rules, approvers and exceptions it involves, and design the decision trace that will feed the graph.
Context graphs: then, now and next
- 2012: Google launches its Knowledge Graph and makes "graph of things" mainstream in search.
- 2024: Microsoft Research publishes GraphRAG, using graphs to improve what language models retrieve.
- December 2025: Foundation Capital argues that decision traces, linked into context graphs, will become a new system of record.
- 2026: vendors from IBM to graph-database and AI-platform companies publish their own definitions, and agents start acting on ERP, CRM and payment systems.
- 2027 onwards: EU AI Act record-keeping duties for high-risk systems (Article 12), with Annex III obligations applying from 2 December 2027, make an explainable decision record a compliance need, not just a nice-to-have.
Where context graphs fall short
- They are only as good as the capture. If reasons are not recorded when decisions are made, the graph is a list of outcomes.
- Old decisions are hard to recover. History that lives in email and memory rarely converts cleanly.
- Precedent can be wrong. A past exception is evidence of what happened, not proof that it was right. Policy must still decide.
- They need ownership. Without a team responsible for each decision type, the graph goes stale.
A context graph is the right investment when decisions are frequent, exceptions are common, and you need to show afterwards why something was done. For rare, low-risk decisions, a simpler log is enough.
Where ElixirData fits
ElixirData's Context OS is built around this idea. Its Decision Traces record every agent decision with full lineage, and its governance gates check policy before an agent reasons and again before it acts. Together these produce the context graph as a by-product of normal work, so it does not need to be assembled as a separate project.
Frequently asked questions
Is a context graph a graph database?
Not necessarily. It is a way of modelling decisions. It can be stored in a graph database, but what makes it a context graph is what it records.
Who owns the context graph?
Usually the team that owns the decision, with the data or platform team providing the store and the controls.
Does it replace a knowledge graph or a data catalogue?
No. It sits beside them and links to them.
Do you need AI agents to benefit from one?
No. The same record makes audits faster and helps new staff learn how exceptions are handled. Agents make the need urgent because they cannot ask a colleague.
What is a decision trace?
The record of one decision: its inputs, the rule applied, who or what decided, any exception, and the outcome. Decision traces are the building blocks of a context graph.
Context graph vs process mining: what is the difference?
Process mining rebuilds the steps of a process from event logs: what happened, in what order and how long it took. A context graph records why each decision in that process was made. Process mining shows where a process slows down; a context graph shows which rule or exception caused it.
Do we have to move our data to build one?
No. Each trace points to the record in your existing systems instead of copying it, and the graph can sit inside your own environment.
Where should we start?
With one frequent, costly decision that has many exceptions, such as invoice tolerances, discounts or access requests. One decision type with good capture beats a company-wide model with none.
Next step: Book a one-day context graph workshop → or see decision traces in a demo.
Related on ElixirData: Decision Graph · Context Graph
Sources
- Jaya Gupta and Ashu Garg, Foundation Capital, AI's trillion-dollar opportunity: Context graphs, 22 December 2025.
- IBM, What is a context graph?, 6 May 2026.
- Microsoft Research, GraphRAG.
