The Context Layer Nobody Built

Most conversations about agents are conversations about models. Which one reasons best, which one is cheapest, which one to standardize on. It is the natural place to look, because the model is the part that feels new.

However, the model is rarely what determines whether an agent is useful inside your enterprise. An agent is only as good as the context it can reach, and your context does not live in the model. It lives across your people, processes, and systems: the CRM, the core system, the document store, the ticketing queue, the human who knows the one exception that matters. Most organizations never built the layer that lets an agent reach that context safely. So the agent either cannot see enough to be useful, or it gets wired in with broad, standing credentials that no security board would ever approve.

That missing layer is the quiet reason most projects stall. It is not a model problem. It is an interoperability and identity problem, and it is unglamorous enough that almost no one budgets for it until they hit it.

The layer is not integration plumbing

The tempting move is to hand this to an integration team and call it plumbing. Resist that, because every design choice in this layer is a security choice, and treating it as plumbing is how the security holes get built in by people who were never asked to think about them.

The context layer has three parts, and each one is where a serious architecture and a hopeful one diverge.

Part one: typed capabilities, not a pile of API keys

An agent needs to read from and write to your systems of record. The lazy way to grant that is a bundle of API keys and broad access. The correct way is explicit, typed capabilities.

Think of each capability as a narrow, named door: read_dossier, request_document, post_decision_for_review. The agent is granted the specific doors it needs for a specific task, and nothing else. Each door is logged.

This is not a cosmetic difference. It changes the sentence your security committee has to evaluate. "The agent can touch our systems" is unauditable, and no one should sign it. "The agent can perform these seven named actions, each logged" is a control a committee can approve. Typed capabilities are what turn an open-ended integration into a bounded, reviewable surface.

Part two: non-human identity, short-lived and least-privilege

An agent is not a person, and it must never borrow a person's credentials.

This is the single most common way projects fail at the security board, because the fast path, running the agent under a developer's personal token with standing production access, is exactly the finding that stops the project. That token is a skeleton key. It is not scoped, it does not expire quickly, and it does not distinguish the agent's actions from the developer's.

In a correct architecture, each agent runs under its own non-human identity, with short-lived, least-privilege credentials and an explicit egress allow-list. The consequence is worth stating plainly: a stolen agent credential is worth almost nothing. There is no static secret to steal, and the identity can only do the few things it was scoped to do, to the few destinations it is allowed to reach. One of these designs passes homologation. The other is the finding that ends the engagement.

Identity is also what makes the audit trail meaningful. When every action carries the agent's own identity and its scoped capabilities, "who did this?" has a precise answer, and the record your auditors inspect actually reconstructs what happened.

Part three: the taint boundary, where untrusted data cannot become privilege

This is the part that separates a serious architecture from a hopeful one, and it deserves care, because it is the most common way agents get compromised in production.

An agent reads content it did not author: a customer email, a scanned contract, a PDF from a third party. That content is untrusted. If a poisoned document contains text that reads like an instruction, and the agent treats it as one, the document has just hijacked an agent with access to your core systems. This is indirect prompt injection, and no prompt, filter, or configuration setting reliably stops it.

The structural answer is a taint boundary: untrusted data never becomes executable privilege. In practice this is enforced by splitting the agent's roles, the pattern known as CaMeL, a dual-LLM design. A privileged planner decides what to do and calls the typed tools, but never reads raw untrusted content directly. A quarantined reader does read the untrusted content, but cannot call tools and cannot act. It passes back a reference, not an instruction. On any ambiguity, the system fails closed.

There is an honest cost. Splitting the roles trades away roughly a few points of utility. That is the deal: a modest accuracy price for a structural guarantee that a document cannot seize control of an agent wired into your core systems. In regulated work, that is not a close call.

No single layer is trusted to hold alone. The taint boundary sits inside defense-in-depth: spotlighting to shrink the attack surface, CaMeL isolation, detection guardrails, and a policy decision point above them all. Spotlighting reduces the attack surface. It does not eliminate it, which is exactly why it is never the only layer.

Why this layer is worth building on your real processes

You cannot buy this layer off a shelf, because it is shaped by your systems, your identities, and your data boundaries. It has to be built on your real processes, forward-deployed, on the actual work, not on a reference diagram.

That is also why it is the layer that quietly decides everything downstream. The best model in the world, routed through the most portable gateway, governed by the most rigorous autonomy ladder, is useless if the agent cannot safely reach the context it needs to act. Conversely, once the context layer exists, agents reach only what they are allowed to, act under their own least-privilege identities, and can never be tricked into treating untrusted data as an instruction, with a full trail your auditors can inspect. Everything else in an agentic architecture assumes this layer already exists.

So the reframe is not "which model should our agents use?" It is for each system our agents must reach, what is the typed capability, what identity does the agent hold, and where is the boundary between the content it reads and the actions it can take? If you cannot answer that per system, the model choice does not matter yet. The layer underneath it has not been built.

If you want to map the context layer for one high-stakes process, book a meeting.