In short
A sales director approves, for a renewal, a discount above the ceiling set by the policy. The CRM starts showing the new amount. The reason stays in the approval conversation: the customer received a proposal from another vendor, and another account in the same sector had a similar deal months earlier. The context graph is the structure that records this why and links it to entities and to time. It extends the knowledge graph of the Company Brain, the layer that knows the company: what data exists, where it lives, how it connects and who may see what.
CRM, ERP and helpdesk are systems of record. They keep the state: the contract value, the payment terms, the credit limit, the ticket priority. Almost none of them keep why that value was accepted in that case.
Exceptions, approvals, precedents and the cross-checking of information between systems stay in conversations, emails and the memory of whoever decided.
In December 2025, Jaya Gupta and Ashu Garg, of the investment firm Foundation Capital, described decision traces as the layer that systems of record leave out. In the piece, they use the term context graph for the structure formed by these traces accumulated across entities and time.
A sales rule defines the maximum discount per contract band. A decision trace records what happened in one case: which policy applied, which exception was requested, who approved, based on which precedent and with which data in view. Some examples:
Each trace links a decision to the entities it affected, to the moment it happened and to the information consulted. Accumulated, the traces form the context graph, and precedent becomes searchable: when a similar exception was granted, by whom and with what justification.
The knowledge graph represents the business entities and the current relationships between them: this customer signed this contract, which gave rise to these orders.
The context graph uses the same entities as anchors and adds one type of node, the decision. Each decision points to the entities it affected, to the rule in force, to the exception granted and to the person who approved. The two structures depend on each other, because a trace without the right entity can only be retrieved by text similarity.
An agent that works only with rules handles the typical case well. Faced with an exception, it applies the rule to the letter or fills the gap with the most likely continuation, and the result departs from the company's practice.
With access to the traces, the agent retrieves similar earlier cases and presents them to the person deciding, with the current policy and the data that supported each approval. The exception decision stays human. The agent prepares the case, the person approves, adjusts or declines, and the trace records who decided and why.
The authors' central argument is about architecture. The trace exists at the moment the decision is made: which data was consulted, which policy was assessed, which exception was requested and who approved. Whoever sits in that execution path records the context graph while the decision happens.
A system that reads the data later, through ETL (periodic loads into the data warehouse), receives the final state. It sees the contract with a discount above the ceiling and does not see the conversation that justified the discount. The why is lost along the way.
A credit exception trace can contain the customer's financial situation and excerpts of internal conversation, and it inherits the sensitivity of every source it consulted.
In the Company Brain, the history of interactions and decisions is recorded alongside the entities in the knowledge graph. A discount approval is linked to the customer, the contract, the opportunity and the person who approved, with the date and the source system. The business ontology defines what each type of decision means.
Permissions are inherited from the source system. A trace that cites ERP data is returned only to people who already see that data in the ERP. The traces stay inside the customer's perimeter, and the relevant slice is served via MCP to the agent preparing the next decision, with the source of each piece of information.
This is an architectural direction, built process by process: the context graph gains value as more decisions pass through the flow where the recording happens.
The recommended starting point is a process with repeated decisions and many exceptions, such as discount approval, credit release or extended payment terms. The first step is to map where approval happens today and which data the approver consults before deciding.
Next, the approval flow starts recording each decision with its justification, approver, policy and entities. Over the following weeks, the team checks whether the retrieved precedents help whoever decides the next exception.
