“Context graph” is now one of the most-discussed ideas in enterprise AI. That alone makes it worth understanding. But it is still early enough that a lot of people are talking about it without quite talking about the same thing.
This analysis tries to separate the useful core from the expanding mythology around it.
My current position is straightforward:
The problem that context graphs are trying to solve is real.
The category itself is still unstable.
The concept is strongest when treated as enterprise decision lineage or operational memory.
It becomes weaker when it starts sounding like a complete answer to customer context.
That is the argument.
What the term is trying to capture
The strongest public formulation comes from Foundation Capital. Their claim is that traditional systems of record capture the final state of the enterprise, but not the missing layer that actually runs enterprises: decision traces. These include exceptions, overrides, precedents, approvals, and cross-system context that often live in Slack threads, deal desk calls, escalation conversations, and human memory. Their “context graph” is the accumulated structure formed by those traces across entities and time — “not the model’s chain-of-thought,” but a queryable record of how decisions were made and why they were allowed to happen.
That formulation is important because it already narrows the term. It does not describe all context. It describes a very particular kind of organizational memory:
- Why this exception was granted,
- Why this approval happened,
- Which precedent mattered,
- What route was taken through policy,
- What changed in state,
- And how that should inform future autonomy.
Read that way, the concept is serious.
Glean broadens the picture slightly by defining context graphs as models that connect enterprise entities such as people, documents, tickets, and systems with temporal traces of actions and events so AI can understand how work actually gets done.
Neo4j leans in from the graph side, positioning context graphs as a way to capture institutional knowledge and support reliable, explainable, enterprise-grade decisions.
Atlan then tries to formalize the distinction by saying a knowledge graph models semantic relationships, while a context graph extends that with operational metadata such as lineage, governance rules, decision traces, and temporal context.
So a provisional definition emerges:
A context graph is a graph of enterprise entities and relationships enriched with operational traces that preserve how work, decisions, and exceptions actually happen across time.
That is plausible. Useful. Also still early.
Why the concept is gaining traction
Three forces are pushing the term upward.
1 Systems of record are too thin
They are very good at storing what exists now. They are weaker at storing the reasoning, precedent, and exception logic that shaped what exists now. Foundation’s “what systems of record don’t capture” section is right on that.
2 Agents need more than retrieval
Tool-using agents need more than factual answers or raw data access. They need process knowledge, memory, and decision relevance. That is why Glean, Neo4j, and others increasingly describe the missing layer as context, not just data.
3 The market is moving from prompt engineering to context engineering
This is the broader frame. Brinker’s recent martech report pushed this direction explicitly, describing CDPs as “context-as-a-service” and treating context-engineering capabilities as a core packaged layer for marketing.
Put differently: the industry has realized that better prompts are not enough. Context infrastructure is becoming the battleground.
That is why “context graph” is resonating.
How real is it?
The best answer is: real in problem diagnosis, uneven in implementation, immature as a category.
Real in problem diagnosis
The gap is obvious. Enterprises do lose crucial operating knowledge in chats, approvals, handoffs, exception handling, and undocumented decisions. Context graphs are trying to name that missing layer.
Uneven in implementation
Bounded implementations are feasible. A graph of tickets, approvals, policies, handoffs, exceptions, agent runs, and related decisions is quite plausible with current graph databases, event models, and retrieval techniques. Neo4j’s positioning around graph-native memory reflects that.
Immature as a category
This is where caution is needed. “Context graph” has not yet become a settled enterprise category in the way CDP, warehouse, CRM, or knowledge graph once did. There is no single architecture canon, no stable buyer category, and no one implementation pattern the market has agreed on.
So the idea is real enough to matter, but not yet mature enough to treat as a settled layer.
The most useful way to understand it
The cleanest way to hold the concept is this:
A context graph is best understood as an enterprise decision graph or operational memory graph.
That means it is strongest when it captures:
- decision lineage,
- approval history,
- policy application,
- exception routing,
- precedent,
- temporal relevance,
- and the cross-system circumstances of action.
That is where the term has the most explanatory power.
It is much weaker when it gets promoted into a claim about context more broadly, especially customer context.
That is where the current enthusiasm starts to blur categories.
The comparison that matters
Here is the cleanest comparison I can offer.
That table captures the heart of my view.
Why Encounter Graph is a stronger concept for Customer Technology
This is where my thinking diverges most sharply from current context-graph hype.
The Encounter Graph is not just another graph label. It is a more disciplined answer to a more specific problem.
The book work defines it as a formal relational substrate for customer engagement where encounters are connected through explicit relation types: identity, intent, time, state, policy, product, channel, and human context. It exists so continuity becomes governable rather than merely observable. Journeys become derived views over that substrate rather than primary doctrine.
That is stronger than most current context-graph rhetoric in at least four ways.
1 It is more serious about boundedness
The book is explicit that you cannot and should not model everything. It argues for governed boundedness, projection, zoom, and selective materialization rather than totality.
2 It is more serious about human context
The Encounter Graph includes relationship condition, situational context, behavioral pattern, and temporal relevance and decay as relational layers beyond identity.
3 It is more serious about continuity and diagnosis
Its purpose is not simply retrieval or agent grounding. It is continuity, contradiction detection, repeat-effort diagnosis, broken handoff visibility, failed recovery detection, and behavioral drift.
4 It is more serious about ownership limits
This is where The Context Fantasy matters. Customer context remains bounded, perishable, and never fully ownable by the enterprise. The graph may help preserve a governed operational view. It does not turn customer reality into a durable enterprise asset.
That last point is the one most current context-graph writing still underplays.
The biggest critique of context-graph hype
The strongest critique is simple:
Context graphs are being marketed as if enterprise decision reality and customer reality were converging into the same thing.
They are not.
A graph of approvals, policies, precedents, documents, agent actions, and workflow traces can be immensely valuable. It can make enterprise autonomy safer and more explainable. It can improve institutional memory. It can even improve customer outcomes indirectly.
That still does not make it the same as customer context.
This is where the current language becomes slippery. Once context graphs, context engineering, agent context, decisioning, and customer understanding start living under the same umbrella, the enterprise can begin to overstate what it can know and what it has any right to claim as context.
That is exactly the problem raised in The Context Fantasy. The enterprise works with an operational view — partial, temporary, perspective-bound, and governed under limits — rather than full possession of customer context.
So the critique is not that context graphs are fake. It is that they are easiest to misunderstand precisely where the language becomes most ambitious.
The missing question: recovery
There is one more gap here that matters.
A lot of the current context-graph conversation is very good at preserving why. It is weaker on what happens when the “why” was wrong.
This is where the relevance of The Decisioning Delusion comes back in. The missing first-class concern in most decisioning rhetoric is reversibility: what happens when a bad interpretation contaminates state, propagates across systems, and now needs to be corrected, compensated for, and re-arbitrated across time. A mature system is not defined by its ability to choose only, but by its ability to recover.
That same critique should be applied to context graphs.
If a context graph becomes the memory layer for agents and enterprise decisions, it also becomes part of the substrate through which mistakes can persist. The question is not only whether the graph preserves precedent. It is whether the surrounding architecture can detect stale or wrong context, unwind consequences, and recover coherently.
That issue is still underdeveloped in the public context-graph discourse.
My current opinion
Here is the cleanest statement I can offer.
Context graphs are a credible and useful emerging pattern for representing organizational decision reality.
They are less convincing when treated as a complete theory of customer context.
Or more sharply:
A context graph may become a very strong system-of-decisions layer. That does not mean it captures customer reality.
That is the opinion I would hold unless the category sharpens significantly.
What to watch next
Three signals will tell us whether context graphs become durable or just another passing abstraction.
Signal 1: bounded real deployments
If enterprises start using them in specific domains — support, approvals, deal desk, contract review, service recovery, exception-heavy operations — that will matter more than broad rhetoric.
Signal 2: category stabilization
If the term starts to converge around a more precise scope — likely enterprise decision lineage and operational memory — it becomes more durable.
Signal 3: governance maturity
If the discourse moves beyond traceability into boundedness, decay, legitimacy, and reversibility, the concept will start to mature.
That is the standard I’d apply.
This analysis draws on:
- Foundation Capital’s thesis that context graphs are accumulated decision traces stitched across entities and time, forming a new system-of-decisions layer.
- Glean’s enterprise implementation framing that context graphs connect entities with temporal traces of actions and events so AI understands how work actually gets done.
- Neo4j’s graph-native positioning of context graphs as institutional knowledge and agent memory for reliable, explainable enterprise decisions.
- Atlan’s distinction between knowledge graphs and context graphs, with the latter adding lineage, temporal context, governance, and decision traces.
- Scott Brinker’s framing of CDPs as “context-as-a-service” and the broader movement from prompt engineering to context engineering.
- My recent essays for Field Bell Institute: The Context Fantasy and The Decisioning Delusion, plus ongoing work on Encounter Graph as a more disciplined relational substrate for Customer Technology.
