Context Intelligence: Why Your Agent Passes Every Test and Fails in Production
Today: The model is no longer the hard part. The advantage now sits in whether your agents know how your business actually works.
An agent quotes a customer an SLA that expired eighteen months ago. It sounded confident, the document it cited was real, and it still got the answer wrong, because the current contract never reached it.
The model did its job. What failed was everything around the model. The context. And that’s the shift worth getting your head around: the intelligence is largely a solved problem now, and the bottleneck has moved to context.
Prukalpa Sankar, Founder and Co-CEO of Atlan, puts it bluntly: with AI, context might be everything, because “the intelligence is already here.” The model is the easy part. The hard, durable, defensible part is whether your agents understand how your business actually works. That understanding is what people are starting to call context intelligence.
What context intelligence actually is
It isn’t a bigger prompt or a better retrieval setup. It’s the infrastructure that gives an agent shared, governed, current knowledge of your organisation, plus a memory of the decisions it and its predecessors have made. Two ingredients: a map of how things relate, and a record of why things happened.
That map and that record are the context graph. A context graph is a living model of your business as a set of entities and the relationships between them, this customer, that contract, this SLA, that exception, joined to the decisions taken against them. Foundation Capital, in their Context Graphs essay by Jaya Gupta and Ashu Garg, made the sharpest version of the argument: the durable asset isn’t the data an agent reads, it’s the decision trace it leaves behind. What was gathered, what rule applied, why an action was allowed. Capture that, and precedent becomes something an agent can look up instead of guess at. The agent stops having data with no judgement and starts having judgement.
Why this is the accuracy story
Most enterprise agents fail on a trust gap, not a model gap. The SLA agent didn’t need a cleverer model. It needed to know which contract was current, that it was allowed to act on it, and what had been decided in similar cases before. None of that lives in the model. All of it lives in the context.
Without it, you get what Prukalpa calls context sprawl: every agent building its own private, partial view of the world, none of them agreeing on what “active customer” even means. Fifty agents, fifty versions of the truth, no shared map. Accuracy in that environment isn’t a model property. It’s an infrastructure property.
This is where the runtime and the infrastructure get confused. Anthropic’s work on context engineering covers the runtime half: context is finite, and the discipline is fitting in the fewest high-value tokens at the moment of inference, not the most. That’s real, but it assumes the right context already exists to be selected. Context intelligence is the layer below it, the one that decides what context exists, whether it can be trusted, and whether the agent may use it. One is what you put in the window. The other is what’s available to put there at all.
How to think about building it
You can read most failures here as three debts coming due.
Data Debt: no single governed source of what’s true, so your agents disagree.
Decision Debt: nobody captured why past actions were taken, so the context graph has no memory.
Evaluation Debt: no framework to check whether the context an agent actually used was the right context. Work out which one is biting and you know where to start.
The build order matters more than the architecture diagram. The instinct is to spend two years plumbing every system into a perfect context layer before anything ships. Prukalpa’s advice is the opposite, and it’s right: bootstrap from the systems you already have, the CRM, the ERP, the BI definitions, get the context layer roughly 80% of the way there, and let the flywheel start turning. Every decision an agent makes then becomes institutional memory the next agent inherits. You don’t design the context graph up front. You grow it.
Which is why this isn’t really an AI problem at heart. It’s the next turn of data engineering: context as a governed product, with owners, versions, and tests, sitting between your data and your agents. The teams who treated data as a product a decade ago have a head start. The ones still treating context as something you cram into a prompt are about to learn the difference in production.
The open question, the one nobody at the table has a clean answer to yet, is who inside the enterprise actually owns this layer.
I got into exactly that with Prukalpa Sankar on the podcast. She’s been arguing for the context layer longer than almost anyone, and it’s the clearest thinking I’ve heard on where this is heading.
Also, read Prukalpa’s article - What an Enterprise Context Layer Actually Is
Enjoy your weekend.
Talk soon,
Sandi
P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.
Ask your friends to join.
More valuable content coming your way.