Why Everyone In AI Is Talking About Context Graphs
TL;DR
As AI agents start to handle more work, the main problem is no longer the model. The problem is context. Systems of record tell us what happened, but not why a decision was made or why a rule was bent. A "context graph" is a record of those decision traces across tools, people, and time.
Most people in large companies know a simple question can have more than one answer. Ask "What is our ARR?" and you get a few different numbers.
Sales points at the CRM. Finance uses its own view with some items removed. Accounting talks about revenue recognition instead of bookings. Legal reminds everyone that some contracts do not match the neat model in the board deck.
Now imagine you tell an AI agent to "calculate ARR by segment and send a deck to the board." The agent has a problem.
Which ARR should it use? Which system is the main source of truth? If the billing system and the data warehouse do not match, which one should the agent trust?
Over the last decade, many teams tried to fix this with data warehouses, lakehouses, and semantic layers. Those systems sit downstream from daily work. They help with reports. They do not run the workflows.
Sales still works in Salesforce. Finance still closes the books in NetSuite. Support still works tickets in Zendesk.
Now AI agents enter the picture. They connect to many systems in the same task. They read from tools and then act in those tools. That makes one thing much more important. Someone has to decide which system owns which fact, for which use, and at which step.
So far, this is about the "what" in the data. What number did we book. What discount did we give. What status did we set on the ticket.
The next idea goes one step deeper. It looks at the "why."
Some investors and operators use the term "decision traces." A rule says what should happen in general. A decision trace shows what happened in one case, and why it was allowed.
Systems of record handle state. For example:
"This renewal closed with a 20% discount."
They rarely explain why:
Why did we allow 20% when policy says 10%? Who approved the extra discount? Which past case did the team use as a reference?
Today, the "why" lives in messy places.
Slack threads. Side chats during meetings. Deal desk calls. A manager's memory. Informal rules passed on in onboarding.
You cannot query that. An AI agent cannot see it in a reliable way.
This is where the idea of a context graph comes in.
When an agent takes part in a workflow, it can see the full context at that moment. For example, in a renewal it can see:
Which systems it read from. Which policy it checked. Whether it followed a normal path or an exception path. Who approved the final choice. What it wrote back to the CRM.
If you start to store those traces instead of throwing them away, you get a new layer of data. You get a record of how decisions were made, not just what the final state was.
Stitch those traces together over time and across entities. Customers, contracts, tickets, incidents, policies, approvers, agent runs. The graph that forms is what people call a context graph.
Take a simple example.
A renewal agent proposes a 20% discount. Policy says renewals can only go to 10% unless there is serious service impact.
A context-aware agent could:
Pull three severe incidents from PagerDuty. Check Zendesk and find an open "cancel unless fixed" escalation. Find a prior renewal where a vice president approved a similar case. Send all this to finance as part of an exception request. Write the approved 20% discount into the CRM.
The CRM now holds one fact: "The renewal closed at a 20% discount."
The context graph holds the story:
Which incidents we used as a reason. Which past case we treated as precedent. Which rule we bent. Who approved the change.
Over time, this builds a body of searchable precedent. The "why" turns into data you can inspect.
You can audit agent decisions. You can see where written policy and real practice do not match. You can turn common "exceptions" into new clear rules.
One risk is the urge to sit in a room and design the perfect schema for this graph. That is how many knowledge graph projects started, and many of them failed.
A different view is to let the structure emerge from use.
Agents "walk" through your systems as they solve problems. They call APIs. They read docs. They look at old tickets and threads. Each run shows which entities matter in practice and how they connect.
If you collect enough of these agent runs and human decisions, patterns appear. You can see which systems people tend to use together. You can see which data points show up side by side in real decisions. You can see how teams resolve conflicts between numbers from different tools.
You may also see that some "exceptions" happen almost every time.
For example, a company may say in policy that all new customers get the same pricing rules. In practice, the team might always give hospitals an extra discount because their buying process is long and hard. That is not in the CRM fields. It is in the shared habits of the team.
A context graph can make this visible. It reflects how the company works in real life, not only how it is written in a slide deck.
This raises a bigger point. If many companies can use similar base models and agent platforms, how do they stay different from each other?
One answer is context.
How well they organize their data for AI agents. How complete and clean their decision traces are. How well people and agents work together on top of that context.
Agents will not bend to every messy habit we have today. To use them well, teams will adjust some workflows so that context is clear and captured by default.
This shifts the role of many knowledge workers.
In the past, they did most of the steps themselves. In the future, they will guide agents, give them the right context, and review their output.
They will decide when to allow an exception, when to hold the line on a rule, and when to change the rule. They will resolve cases where data and precedent pull in different directions.
These are still human judgment calls. They draw on experience, values, and a feel for the situation. That is why they are so important to store.
You can think of a context graph as a way to keep a memory of those calls. It gives agents and humans a shared record of what the company did in the past and why.
So when you hear people talk about context graphs this year, you can keep a simple definition in mind.
A context graph is a living record of decisions, connected to the data and people behind them. It links the "what" in your systems of record to the "why" in your real work.