Context engineering is not context management

It's Monday. A regional metric has dropped sharply and the executive team wants an explanation by Wednesday.

What follows is familiar. You find a dozen datasets with near-identical names, none carrying quite the field you need, and documentation that was last accurate two quarters ago. Access requests queue behind approvals. When the data finally arrives it has gaps that take hours to reconcile. By Wednesday almost all of your time has gone into finding and validating data, and almost none into the actual question.

There's a second cost people tend to skip past. When data is hard to get to legitimately, people route around it. Shared credentials, ungoverned exports, a spreadsheet emailed to someone's personal account. Every workaround is an exposure nobody approved and nobody is tracking.

Now run that same Monday with a thousand agents working in parallel at machine speed. Each one needs the right information in its context window. Without a reliable system to deliver it, they either stall or invent. And unlike your operations lead, an agent will not walk over and ask whether it has the right table. It will confirm your assumption and hand you a number.

The gap most organisations won't admit

Survey data on this is worth reading carefully, because it contradicts itself in a specific way. A large majority of leaders say they already have a working way to get context to humans and AI. Around the same share say they routinely delay AI initiatives because they don't trust their data, and name data readiness as the single biggest obstacle to getting agents into production.

Both things can't be true. Most organisations believe the problem is solved. Very few have solved it.

Three approaches, and where each one stops

The way to understand what's missing is to trace what each previous approach couldn't do.

Prompt engineering taught us to ask precisely, give good examples, and shape the output. It works for a single question. It breaks the moment a task needs a large knowledge base or several steps, and no context window gets big enough to hold an enterprise.

Retrieval-augmented generation was a genuine breakthrough and still is the right pattern for grounding answers in enterprise knowledge. But its reliability is entirely inherited from what sits underneath it. Without a governed foundation, every team builds its own retrieval path, its own vector store, its own embedding model, its own idea of what counts as trustworthy. Nothing is shared and nothing is comparable.

Context engineering pulled memory, tool calling, structured outputs, guardrails and prompt management into one coherent toolkit. It gives real control over what enters a context window and how it's arranged.

It's the best of the three, and it still leaves the load-bearing questions open. Where did this context come from. How do I know it's trustworthy. How do I keep it consistent across applications. How do I govern access when there are two hundred agents instead of two.

Context engineering hands you the blocks. It doesn't tell you which to use, where to find them, or whether they're safe to build with.

The distinction that matters

Context engineering solves the problem inside one application. It's what a team does to fill its own agent's context window well. It tends to be bespoke, and bespoke doesn't scale sideways.

Context management solves it across the organisation. It's the capability that lets any agent, built by any team, discover context, trust it, and use it under policy.

The analogy is authentication. Context engineering is each product team writing its own login. Context management is enterprise single sign-on. Both get users through the door. Only one is still maintainable at two hundred applications.

What context actually contains

"Context" gets used loosely, so it's worth being precise. It's everything an organisation knows about its data, connected into one structure, and it has four layers.

Technical covers the assets themselves, the datasets and pipelines and dashboards and the services that produce and consume them, connected through schema, lineage and query logic.

Operational covers freshness, profiles, column statistics and quality results. It answers whether the data can be trusted right now rather than in principle.

Business maps your vocabulary onto that structure through domains, data products, glossary terms and documentation, turning a static glossary into a live model of meaning.

Organisational captures the people, teams and roles that own and grant access, connecting individuals to what they're accountable for.

Those four layers are the context primitive. Semantics and memory sit alongside it, and the three together are what an agent actually needs. Context tells an agent what exists. Semantics tells it what that means. Memory tells it what the organisation has already decided.

What agents need from it

If agents could specify their requirements, they'd ask for three properties.

Relevance. Context has to fit the question at hand, which means semantic search over what matters rather than a dump of what exists. Last quarter's definition doesn't help with this quarter's problem.

Reliability. Context has to carry provenance. Where did this come from, can I trace its lineage, who approved it. This matters most when agents hand work to other agents, and when someone asks six months later how a decision got made.

Retention. Context has to persist across sessions, so that a correction made once applies afterwards. Retention is a maintenance problem as much as a storage one: definitions drift, sources go stale, and things quietly stop being true. Something has to notice.

An application-level approach can deliver all three inside one tool. Only an organisation-level one delivers them everywhere.

Why the timing is unforgiving

Every team is currently building its own context solution. One picks a vector database, another picks a different one, a third writes its own. Deployed across platforms with different limits and different security models and no shared source of truth, your customer-facing agent and your internal agent answer the same question differently. Neither is obviously wrong. Nobody can say which is right.

We have seen this exact movie with microservices, where letting every team build independently produced sprawl and then an expensive consolidation. The difference is speed. That took years. This is taking quarters.

Two things make it more expensive than the microservices round. As agents gain autonomy, regulators will ask what an agent did and why, and without provenance there's no answer that survives an audit. And underneath the compliance exposure is the thing that's harder to rebuild: when agents contradict each other and can't explain themselves, people stop handing them work that matters. The risk isn't that AI fails. It's that trust runs out before it gets the chance to succeed.

Capability, and the thing that delivers it

Context management is the capability. A context platform is the infrastructure that delivers it. One can be described in a strategy document. The other has to ingest from every system you own, hold definitions that survive expert review, enforce policy at retrieval time, and serve agents at machine speed.

Two architectural choices separate real ones from catalogs with AI features attached.

The first is where authorisation happens. Agents make thousands of requests a minute, chain sources inside a single workflow, and have no instinct for when an access pattern feels wrong. Perimeter security doesn't survive that. Access control has to be enforced at retrieval, before context reaches the model, with every piece carrying its source, its freshness and the policy that permitted it.

The second is whether the substrate is a current-state store or an event log. Most products in this category were built as a relational store behind a browsable interface, and are being retrofitted for query rates nobody designed for. A system built on a connected graph and an event log can reconstruct how any definition looked on any date, which turns context from a lookup into an evidence trail.

One question to ask any vendor

Ask what happens when you enquire about something that changed this morning.

If the answer is that you'll see it tomorrow, the context reaching your agents is already stale, and everything above is theoretical.

The bottom line

Build context management and your agents can be trusted with work that matters. Skip it and you get a thousand eager agents giving confident wrong answers, faster than anyone can check them.