Your company records what happened. Almost nothing records why.

The discount nobody can explain

Open any closed deal from eighteen months ago. Your CRM will tell you something like this:

• Opportunity: closed won
• Discount applied: 20%
• Approved by: (field empty)

Now ask the question an AI agent will ask next quarter, when a similar account lands on its desk: should I approve this again?

The record cannot answer. The answer lived in an incident postmortem, a support escalation thread, a fifteen minute call that was never written down, and a VP's judgment about a two year renewal. Three of the five people involved have since changed roles.

Your company did not lose the data. The data is all still there. It lost the reasoning, and the reasoning was the valuable part.

Data tells you a discount was 20%. Context tells you it was the price of keeping an account that had already threatened to leave.

Every business runs two clocks

This is the cleanest way we have found to explain the gap to a leadership team. Your organisation keeps time twice, and you have only ever bought software for one of them.

State clock: what is true now

Salesforce, SAP, Workday, ServiceNow, Jira. Thirty years of engineering, near perfect.

• The contract is signed
• The ticket is resolved
• The timeout is set to 30 seconds
• The account is flagged high risk

Event clock: how it became true

Slack, meetings, inboxes, corridors, and one person's head. Almost no engineering at all.

• What signal arrived first
• Who decided, and on what basis
• Which policy applied, and which exception was granted
• What we rejected, and what happened next

We automated the state clock and left the event clock to humans. Then we called it experience, paid a premium for it, and watched it walk out of the door every time someone resigned.

That trade was acceptable while humans made all the decisions. It stops being acceptable the moment software starts making them.

So what is a context graph?

Strip away the vendor language and it is simple. A context graph is a living, connected record of your entities, events, decisions, policies, people and outcomes, where the connections carry the reasoning, not just the relationship.

A knowledge graph says: account A is linked to ticket B.

A context graph says: ticket B is why account A got an exception, here is who approved it, here is what was known at the time, and here is whether it worked.

Look at the same renewal through both lenses.

What your systems keep

• Renewal closed
• Discount 20%
• Term: 24 months

Three facts. Perfectly accurate. Completely unusable as precedent.

What actually happened

1. Three critical incidents in one quarter (root cause: service side, not customer config)
2. Escalation opened by the account team
3. Churn risk flagged (similar exception granted to this account last year)
4. 20% discount proposed by the deal desk
5. Policy exception required (standard ceiling is 12%)
6. VP approval granted (condition: two year term, not one)
7. Renewal signed, account retained 24 months

One of these teaches a future decision maker, human or machine. The other does not.

Multiply that chain by ten thousand decisions and you have something no competitor can copy: a searchable record of how your organisation actually exercises judgment.

The point was never to draw a pretty graph. The point is to answer questions that matter: why did this happen, who approved it, what was known at the time, which precedent applied, and did it work.

This is not "memory for agents"

Nearly every write up on this topic calls a context graph "memory". That is directionally right and practically misleading. Memory is what an agent recalls about a conversation. A context graph is what an agent understands about a business.

• Tools. The ability to act. Your agent can update the CRM.
• Skills. Instructions for a task. Your agent knows the steps of a renewal.
• Memory. Recall of past interactions. Your agent remembers what this customer asked last month.
• Context graph. Judgment. Your agent understands relationships, precedents, exceptions and consequences across the whole organisation.

The difference shows up the instant a hard case arrives. An agent with the first three layers retrieves. An agent with the fourth reasons:

"This account resembles three earlier cases. Two got the exception because the incidents were service side. One was refused because the root cause was the customer's own configuration. This one looks like the first two."

That is the line between retrieval and judgment, and it is where the commercial value sits.

Why almost nobody has one yet

Because you cannot buy it. Loading your documents into a graph database gets you a nicer search index, not a context graph. Five things make this genuinely difficult.

1. Identity is fragmented. The same person is three identities across email, chat and the CRM. The same customer has different keys in billing, support and sales.
2. Decisions are invisible. The decision happens in a meeting or a private message. Only the resulting field update is ever written to a system.
3. There is no stable schema. No organisation has a fixed model of how work really gets done, and the real process drifts from the documented one within weeks.
4. Outcomes arrive late. The consequence of a decision shows up months later, long after anyone would think to connect the two.
5. Meaning is not integration. Joining systems tells you what happened and when. It does not tell you what it meant, who was accountable, or what it caused.

Which is why the context graphs that work are not modelled in advance by a consulting team. They are grown from real work: agent trajectories, human approvals, tool calls, workflow transitions, repeated exceptions and observed outcomes. Your true operating model emerges from the traffic, it is not declared upfront.

Follow the glue roles

Context graphs do not pay off evenly across a business. They pay off spectacularly in a specific kind of workflow. Four conditions:

• Several disconnected systems must be consulted before anyone can decide
• Exceptions are frequent enough that the policy alone is never sufficient
• The decision depends on experience, and the experienced person is a bottleneck
• The system of record captures the outcome, but never the reasoning

Tick three of four and you are looking at your first context graph. In practice that means:

• Deal desk and pricing approvals
• Customer escalations
• Compliance and risk review
• Underwriting
• Financial reconciliation
• Security incident response
• Procurement and contracts
• Production engineering

Notice the pattern. These are exactly the places where companies invent roles like RevOps, DevOps, Sales Engineering and SecOps. Those roles exist because context does not travel between systems, so you hire humans to be the integration layer and carry it in their heads.

When an agent takes on that work, faster execution is the small prize. The large prize is that the context finally gets written down.

Ask a better question about your agents

Most AI pilots are evaluated on the wrong question: can the agent complete the task? Plenty of agents can. Almost all of them plateau, because task number five thousand is no easier than task number one.

The question we think separates the winners is this one:

Does every task your agent completes make the next decision better?

If the answer is no, you bought automation. If the answer is yes, you are building an asset that compounds. And compounding requires capturing context at the moment of the decision, not reconstructing it a year later from log files and stale documents.

You do not need full autonomy to start. You need a loop:

1. The agent gathers the relevant information across systems
2. It surfaces the policies and precedents that apply
3. It proposes an action, with its reasoning attached
4. A human approves, edits or rejects it
5. The full decision trace is recorded, including the override
6. The outcome is linked back weeks or months later

Then the next decision starts from a smarter baseline

Step four is the one executives underestimate. Every human override is a labelled example of your company's judgment, and today you throw almost all of them away.

Run that loop for a year and automation stops being a cost line. Your organisation's judgment becomes structured, inspectable and reusable, which is the only durable moat left when everyone has access to the same models.

How to know if you have one

You do not have a context graph because you bought a graph database. You have one when your AI system can answer, with evidence:

"Why does this precedent apply here, and where does it stop applying?"

A real one lets you explain decisions to a regulator, audit what your agents did and why, reuse what worked, spot recurring failure patterns, simulate an alternative path, and stop depending on the six people who remember how things really work.

The next decade of enterprise AI will not be won by the companies with the most data. Every serious company already has more data than it can use. It will be won by the companies that understand how their data turns into decisions, and who keep that understanding where software can reach it.

Not more information. Institutional intelligence that compounds.

Your move this week

1. Pick one workflow and test it against the four conditions. Several systems consulted. Exceptions common. Experience required. Outcome recorded, reasoning lost.
2. Find one decision made in the last month in that workflow.
3. Try to reconstruct why it was made, using only your systems of record.
4. Time how long it takes, and note how much you had to ask a person.

That gap, in minutes, is the size of your opportunity.

This column first appeared in the iaKOR newsletter, Issue 01.