The Decision Trace
Is the Record.

In December 2025, Foundation Capital partners Jaya Gupta and Ashu Garg published a tight, well-argued thesis about where the next trillion-dollar enterprise software platforms will come from. Their answer is not the AI model layer. It is not the warehouse layer. It is the accumulation of decision traces, the structured record of how AI agents, operating at the intersection of multiple systems, turned context into action.

The framing that makes the piece sharp is a distinction that most enterprise AI discussions flatten. There is a difference between rules and decision traces. Rules tell an agent what should happen in general: "use official ARR for reporting." Decision traces capture what happened in this specific case: "we used ARR definition version 3.2, with a VP exception approved on this date, because of precedent set in deal X, and here is what we changed." Agents need both. Most enterprises have only the first.

Gupta and Garg are explicit about why this matters: "The wall isn’t missing data. It’s missing decision traces." The exception logic that governs real enterprise decisions lives in Slack threads, in the heads of people who have been around long enough to know why the last override happened, in approval chains that occur on Zoom calls and are never written to a system. When an agent hits this wall, it cannot proceed, not because the model is weak, but because the organizational memory it needs was never captured as data in the first place.

The accumulated structure formed by those traces is what Foundation Capital calls a context graph: not a chain-of-thought, but a living record of decision traces stitched across entities and time so that precedent becomes searchable. The feedback loop, captured traces becoming searchable precedent, every new decision adding another trace, is what makes this compound. The layer with a structural advantage in capturing those traces is whichever system sits in the orchestration path at decision time, seeing the full context as it happens rather than receiving state after the fact via ETL.

Foundation Capital’s diagnosis is precise in a way that matters for anyone building enterprise AI. The problem is not that enterprise data is messy or siloed. Most large organizations have invested heavily in data infrastructure over the past decade. The modern data stack is, in many places, good. The problem is that the reasoning connecting data to action was never treated as data in the first place.

Four categories make this concrete. Exception logic that lives in people’s heads: "we always give healthcare accounts an extra 10% because their procurement cycles are brutal." That is not in the CRM. It is tribal knowledge passed down through onboarding and side conversations. Precedent from past decisions: "we structured a similar deal for Company X last quarter, we should be consistent." No system links those two deals or records why the structure was chosen. Cross-system synthesis: the support lead who checks ARR in Salesforce, open escalations in Zendesk, a Slack thread flagging churn risk, and decides to escalate. The synthesis happens in their head. The ticket just says "escalated to Tier 3." And approval chains that happen outside systems: a VP approves a discount on a Zoom call. The opportunity record shows the final price. It does not show who approved the deviation or why.

The implication for enterprise AI is direct. An agent that can query every system in your stack but cannot access the reasoning layer is a faster version of the problem you already have, consistent execution on explicit rules, combined with complete opacity on the exceptions and precedents that govern most decisions. The agent will execute the rule. It will miss the exception. And unlike the human who knew the exception, the agent will not even know it missed something.

This is where the context graph becomes load-bearing. Capturing decision traces turns the reasoning layer into queryable data. The approval chain from the Zoom call becomes a structured record. The healthcare exception becomes a searchable precedent. The cross-system synthesis the support lead did in their head becomes an auditable event. Not by rearchitecting any existing system, but by instrumenting the orchestration layer that agents already run through.

And here is the LazyFox complement that Foundation Capital’s framing points toward: for decision traces to be reliable, the semantic inputs they record must be governed. The trace that says "ARR was $2.4M at decision time" is only useful if "ARR" means the same thing to the agent that ran the workflow, the finance system that holds the number, and the executive reading the audit. Without a governed semantic layer, the context graph captures what happened, but not whether it happened against a consistent, agreed-upon definition of reality.

Foundation Capital’s analysis of why existing players cannot build the context graph is the sharpest section of the piece, because the argument is structural rather than competitive. It does not claim incumbents are too slow or too legacy. It claims they are in the wrong place in the data flow.

Operational incumbents (Salesforce, Workday, ServiceNow) are built around current state storage. Salesforce knows what the opportunity looks like now. It does not know what the world looked like when the discount was approved: which incidents were open, which escalation was live, which precedent was invoked, who was in the room. When a discount gets approved, the context that justified it disappears. You cannot replay the state of the world at decision time. You cannot audit the decision. You cannot use it as precedent. And because Salesforce only sees its own objects, it inherits its own blind spots: a support escalation that depends on customer tier from CRM, SLA terms from billing, recent outages from PagerDuty, and a Slack thread flagging churn risk is invisible to any single-system agent.

Warehouse players have a different problem. Snowflake and Databricks receive data via ETL after decisions are made. They have time-based views, you can query historical snapshots, compare metrics across periods, but by the time data lands in the warehouse, the decision context is gone. The warehouse sees the 20% discount. It does not see the three SEV-1 incidents, the VP exception, or the precedent from Q2 that made the approval legitimate. Databricks is further along in putting the pieces together. But being close to where agents get built is not the same as being in the execution path where decisions happen.

Incumbents will fight back, Foundation Capital notes, with acquisitions, API lockdown, and egress fees, the hyperscaler playbook. But that playbook assumes you can bolt on orchestration capabilities after the fact. Capturing decision traces requires being in the execution path at commit time. You cannot insert yourself into an orchestration layer you were never part of.

The LazyFox parallel is precise. Semantic incumbents have the same structural problem. A data catalog that was built to document schema state cannot govern metric definitions across systems in real time. A BI semantic layer that was built for a single tool cannot reconcile meaning across CRM, warehouse, and finance system simultaneously. The context graph Foundation Capital describes needs a semantic foundation that is also in the execution path, sitting above all connected systems, governing definitions at query time, not documenting them after the fact.

The most important claim in Foundation Capital’s piece is not about what context graphs capture. It is about what happens to them over time. "The feedback loop is what makes this compound. Captured decision traces become searchable precedent. And every automated decision adds another trace to the graph."

This compounding dynamic is real and it is why the context graph will become the most valuable asset in the enterprise. But it rests on a precondition that the article gestures toward without naming: the semantic inputs feeding the context graph must be consistent. A decision trace that records a 20% discount being approved on an ARR of $2.4M is only useful as searchable precedent if "ARR" means the same thing to the agent that ran the workflow six months ago, the finance system generating next quarter’s renewal list, and the executive reading the audit today.

Semantic drift is quiet and it compounds in the wrong direction. When the definition of "ARR" shifts, when a new product line launches, when a migration changes the source table, when finance and sales adopt different recognition conventions, the context graph does not break immediately. It accumulates subtly inconsistent precedents. The 20% discount approved six months ago was against ARR definition v3. Today’s agent is running against ARR definition v7. The precedent still matches superficially. The numbers are off.

LazyFox’s semantic drift detection is the architectural complement Foundation Capital does not name. When a definition diverges across connected systems, when the CRM, warehouse, and finance system are using different versions of "ARR", LazyFox flags it before agent queries run against inconsistent data. Every decision trace captured in the context graph is grounded against a governed definition, versioned at the moment of capture. The precedent chain stays reliable as definitions evolve, because each trace records what happened and which version of "what" was in scope when it happened.

Finway shows the same loop at the semantic layer. Reporting logic it used to copy into each hand-written query now lives once in a governed layer that every report reuses, which is why a new report takes hours instead of a couple of weeks. Each definition captured, conflict surfaced and drift event detected adds to that layer, and each metric’s health is tracked against it, so the governed context grows with use. A decision trace is only as trustworthy as the definitions it queried at decision time, which is why the two layers compound together.

• Can you replay the state of the world at decision time? If your record shows the final discount but not the incidents, escalation, and precedent that justified it, you have an outcome, not a trace.
• Are the definitions your traces record versioned? A precedent approved against last year's ARR definition quietly misleads the moment that definition changes and nothing flags it.
• What reconciles a term when two systems define it differently? If "active customer" or "cancelled" means one thing in the CRM and another in the warehouse, every trace built on top inherits the conflict.
• Does each trace name the definition version it relied on, and who approved that version? Without both, a precedent cannot be defended once someone asks why it applied.
• Does the governing layer sit above all your systems, or inside one of them? A layer tied to a single system captures only that system's slice of the decision, and follows its roadmap and pricing.

The context graph captures what happened. Governed meaning is what keeps it trustworthy after the definitions move underneath it. Teams that evaluate the two separately will know exactly what they are building, and what they still need to buy.