What a context graph is, per Foundation Capital’s essay, and why a decision trace that records its reasoning but not the state it read can’t be audited.
TL;DR: A context graph, in Foundation Capital’s framing, is the accumulated record of decision traces: who decided what, under which policy and exception, linked to the entities involved. It’s valuable only if each trace can be trusted later. That requires recording not just the reasoning but the exact state the decision read, from one consistent point in time. A trace that says “approved because the customer had no prior refunds” is useless if you can’t show what the refund history said at that moment.
Your agent approved a refund exception three weeks ago. Today a reviewer asks why. The trace says: policy v3.2 allows one exception per customer per quarter; the customer had no prior exceptions; approved. The reviewer opens the customer record and finds an exception granted two days before this one.
Was the agent wrong? Or did the earlier exception not exist yet in the system the agent read? Maybe it was granted in a different tool and synced an hour later. The trace can’t say, because it recorded the conclusion (“no prior exceptions”) and not the evidence (the rows it read, and as of when).
That question is about to matter a lot more. A venture essay from Foundation Capital argues that decision traces like this one become the most valuable data an enterprise has. This post covers that argument, then the part it leaves for engineers to work out: what a trace needs to record to be worth keeping.
A context graph is a connected record of decision traces: each automated or human decision, the inputs it used, the policy and exceptions that applied, who approved it, and links to the entities it touched. Over time the traces form a graph of precedent that later decisions, auditors and agents can query to learn why things happened, not only what happened.
This sense of the term comes from AI’s trillion-dollar opportunity: Context graphs, by Jaya Gupta and Ashu Garg of Foundation Capital. Their core distinction: “Rules tell an agent what should happen in general,” while “decision traces capture what happened in this specific case.” They call the accumulated structure of those traces a context graph, “a living record of decision traces stitched across entities and time so precedent becomes searchable.”
Search for the term and you’ll find two different ideas under one name.
A knowledge graph with context. The arXiv paper Context Graph by Chengjin Xu and six co-authors, first posted June 17, 2024, uses the term for an extension of the knowledge graph. Triple-based knowledge graphs, it argues, “lack the contextual information of relational knowledge, like temporal dynamics and provenance details.” A context graph adds “additional information such as time validity, geographic location, and source provenance” to each fact. The unit is still a fact about the world.
A graph of decision traces. Foundation Capital’s essay, posted December 22, 2025, uses the term for something else: a record of decisions, the policies and exceptions behind them, and the entities they touched. The unit is a decision.
The two overlap. A decision trace needs provenance and time validity for the facts it read, which is exactly what the first sense adds. But they answer different questions. The first asks what was true about the world and on whose authority. The second asks what was decided, on what evidence, and whether that evidence was right. This post uses the second sense.
Same name, different unit: a tagged fact on the left, a decision and its evidence on the right.
The essay’s larger claim is about where enterprise value sits. The last generation of enterprise software won by becoming the system of record for objects: in the essay’s words, “Salesforce for customers. Workday for employees. SAP for operations.” Foundation Capital argues the open question is “whether entirely new ones emerge—systems of record for decisions, not just objects.”
The reasoning, the exceptions and the approvals behind a decision mostly live in Slack threads, emails and people’s heads. A follow-up, Why context graphs are the missing layer for AI, puts it plainly: that reasoning “is scattered across tools like Slack, email, and support tickets, or never recorded at all.”
Agents change this because they sit in the path of the decision. The original essay notes that the orchestration layer “sees the full picture: what inputs were gathered, what policies applied, what exceptions were granted, and why,” and so “it can capture that context at decision time—not after the fact via ETL.”
That last phrase is the engineering requirement hiding inside the strategy argument.
Most trace designs record the reasoning well. The model’s chain of thought, the tool calls, the policy version and the approver are easy to log. What gets lost is the state of the world the decision saw.
A trace that records “the customer had no prior exceptions” is a claim. A trace that records the query, the rows it returned and the point in time those rows were current is evidence. Only evidence lets you answer the reviewer’s question: was the decision wrong given what it saw, or was what it saw wrong?
Most traces record the conclusion. The field that makes them auditable is the one left blank.
Without the read point, precedent is unreliable in both directions. A later agent that finds this trace and treats it as precedent (“we granted an exception in a similar case”) inherits whatever was wrong with its inputs.
| Trace field | Typical today | Needed to audit or replay |
|---|---|---|
| Decision and outcome | Recorded | Recorded |
| Policy and version | Often recorded | Recorded |
| Reasoning | Model output logged | Recorded |
| Inputs | Summarized in the reasoning | Values read, with the source of each |
| Read point | Missing | One consistent snapshot, identified by a commit point or row versions |
| Concurrent decisions | Missing | Other decisions on the same entities in the window |
Recording what a decision read sounds simple. It’s hard because most decisions read from several systems.
An agent handling the refund might read the customer from a CRM, refunds from a billing system, a derived risk score from a feature pipeline and similar past cases from a vector store. Each answered about a different moment. The CRM was current. The billing replica was two seconds behind. The risk score was computed by a job that last ran four minutes ago. The vector index was rebuilt overnight.
There is no single “as of” for that decision, because the context it read never existed together at one moment. You can log a timestamp per source, but you can’t reconstruct the state the decision acted on, because it was never one state. This is the context gap applied to audit: a decision acting on context that is incomplete, inconsistent or outdated, and a trace that faithfully records the inconsistency without being able to explain it.
Three ways to record what was read. First, copy the values into the trace. Simple and self-contained, but traces grow large and you lose how derived values were computed. Second, record row identifiers plus versions or a commit point, and keep enough history to look them up. Compact, but it only works if the decision read from a store that can name one consistent point. Third, event-source the inputs and replay. Thorough, and expensive to build across systems you don’t own. In practice, teams copy the small things that matter (balances, counts, scores) and reference the large ones (documents, histories).
“Graph” describes how traces relate: decisions link to customers, policies, approvers and earlier decisions. That shape doesn’t require a graph database. Precedent queries are often a join and a filter, and a recursive query covers chains of related decisions.
A minimal decision record. The edges are references to other rows; the evidence is a column.
CREATE TABLE decisions (
decision_id uuid PRIMARY KEY,
kind text NOT NULL, -- 'exception', 'approval', 'hold'
customer_id bigint NOT NULL, -- edge to the entity
policy_id text NOT NULL, -- edge to the rule, e.g. 'refund-exception-v3.2'
precedent_ids uuid[], -- edges to earlier decisions it relied on
outcome text NOT NULL,
rationale text, -- the model's or approver's reasoning
approver text,
inputs jsonb NOT NULL, -- the values the decision read, copied
read_point text NOT NULL, -- commit point or snapshot the inputs came from
decided_at timestamptz NOT NULL DEFAULT now()
);
-- Exceptions granted under the same policy to customers
-- with a similar risk tier in the last 90 days
SELECT d.decision_id, d.customer_id, d.outcome, d.rationale,
d.inputs ->> 'refunds_90d' AS refunds_at_decision
FROM decisions d
JOIN customers c ON c.customer_id = d.customer_id
WHERE d.policy_id = 'refund-exception-v3.2'
AND d.kind = 'exception'
AND d.inputs ->> 'risk_tier' = 'B'
AND d.decided_at > now() - interval '90 days'
ORDER BY d.decided_at DESC;
Notice refunds_at_decision comes from the trace’s own recorded inputs, not from today’s customer record. That is the whole point: precedent should be judged on what the earlier decision saw.
If your precedent queries are deep, variable-length traversals across many relationship types, a graph engine is the right tool for that query. The requirement in this post, recording a consistent read point, applies either way.
The essay describes a feedback loop: “Captured decision traces become searchable precedent,” and every automated decision adds another trace. That makes traces context, and context has a freshness requirement.
Suppose two agents evaluate exception requests for the same customer at the same moment. Each queries precedent, finds none this quarter, and grants one. Policy allowed one. The second agent needed to see the first agent’s decision, written seconds earlier, and it didn’t, because traces were batched into the graph every few minutes.
A decision record that arrives late is precedent for the audit and stale context for the next decision. If decisions read precedent, decision records have to be written where the next decision reads, and conflicting decisions on the same entity have to be coordinated when they are written. Race Conditions Between AI Agents and Agentic TOCTOU cover that failure.
Not everyone buys the framing. In Context Graphs: Transformational Architecture Or Familiar AI Hype? (January 13, 2026), Verdantix analyst Aleksander Milligan argues that “the distinction between a knowledge graph and a context graph is incremental rather than transformational,” and that “a lot of valuable context is often unrecorded or too ambiguous to translate cleanly into structured representations.”
His sharpest point is about precedent. Inferring intent from ambiguous statements, he writes, “risks encoding one-off exceptions or decisions as repeatable workflow pathways, potentially propagating incorrect precedents or introducing non-compliance risk.”
The ambiguity he describes lives in context pieced together from Slack messages, email and conversations. It applies much less to the structured part of a trace that an agent captures at the moment it decides: the policy version, the values it read and the point in time they were read. That part isn’t ambiguous, and it’s the part that lets a reviewer tell a bad precedent from a good one. Whether or not the graph is new, that evidence is what makes a trace worth keeping.
Tacnode is not a graph store, and it doesn’t build context graphs. It holds the decision context that makes a trace trustworthy: what a decision read and what it decided.
One read point. When a decision reads its context from the Tacnode Context Lake™, raw rows and derived values such as refunds in the last 90 days or a risk tier are evaluated under one snapshot. Data your own systems hold arrives by change data capture, and derivations over it are internally coherent with the same set of ingested events. The trace can record one read point instead of a list of sources at different moments.
Decision records as context. Verdicts, exceptions, holds and agent actions can be written to Tacnode as the system of record for that data, which is what a decision ledger describes. Those writes are ACID transactions, so the decision record and the inputs it copied commit together, and two conflicting exceptions for the same customer are serialized rather than both granted. The record is then context for the next decision that reads precedent.
A context graph built by an orchestration layer or a graph engine can sit on top of those records. What Tacnode adds is that each node in it records a state that actually existed, which is the decision coherence a trace needs before anyone can trust it as precedent.
Former Meta and Microsoft. Built distributed query engines at petabyte scale. Author of the Composition Impossibility Theorem (arXiv:2601.17019).
Fresh Context Newsletter
The argument behind the posts — what breaks when AI acts on stale data, from the team building the Context Lake. About twice a month.
Book a demo and discover how Tacnode can power your AI-native applications.
Book a Demo