Context layer architecture that holds up under audit

One governed door, two planes behind it, and a single ordering decision that separates a real control from a leak. Get that one wrong and the box diagram still looks right.

We have argued that enforcement, not documentation, is what governs an agent. Enforcement has to live somewhere, so this piece is about the structure that carries it, written for the people who will actually build or buy the thing. The hard parts of a good context layer architecture come down to a couple of specific decisions, and if you lead engineering, this is where the thesis becomes a design you can hold your teams to.

Start with what it is not. It is not a new database you migrate everything into. Your warehouse, your catalogue, your fraud platform, your case-management system stay authoritative and stay where they are. The layer is a thin, federated tier that sits between your agents and those systems, assembles task-scoped context from them, and enforces authority as agents act. It mediates access; nothing moves into it. If a design starts by asking you to move your data into it, that is a different and more expensive product.

One governed door

A control you can bypass is not a control. That is the whole reason the architecture has a single entry point, the context gateway: every agent request passes through it, and nothing reaches the source systems directly. So there is exactly one place where policy, redaction, grounding, and quality checks are applied, and no way around them. Take away that single door and every one of those checks has to be enforced and audited in each agent integration separately, forever.

The gateway is deliberately thin. It holds no business meaning and no policy of its own: it validates the request, orchestrates the components behind it, enforces the policy decision, and packages the result. The meaning and the rules live behind it, not in it, so the door itself never becomes another system you have to govern.

It is also protocol-agnostic, which matters more than it sounds. On the side facing agents it is a server, presenting itself in whatever protocol the agent speaks: MCP, A2A, or plain REST and gRPC. On the side facing sources it is a client, connecting however each source expects: MCP where a warehouse exposes it, and a database driver, an API, or an event stream for the rest. The protocol on the wire changes; the door does not. That is what lets a single governed entry point sit in front of systems that each speak something different, without rebuilding any of them.

The two planes of a context layer architecture

Behind the gateway sit two planes and an assurance spine.

The context plane is what is known. A governed semantic and metrics layer with deterministic definitions, so every agent computes the same 'revenue' instead of guessing SQL. An entity-resolution service that reconciles a customer or account or case across systems. A skills-and-playbook registry for how regulated work is actually done. A lineage-and-evidence resolver that attaches source, freshness, and confidence to every item, with grounding treated as a verified control so cited sources are checked to actually support the claim rather than assumed to. And assembly: task-adaptive hybrid retrieval with reranking, using graph structure only where multi-hop reasoning or auditability earns back its cost rather than defaulting to an expensive knowledge graph because it sounds thorough.

The control plane is what is permitted, and proven. An identity-and-purpose binder that fuses the accountable principal (a person, or a governed non-human identity with a named owner), the agent, purpose, and channel into one bound principal. An entitlement-and-policy engine returning allow, deny, redact, or require-approval. Tool authorisation as a separate guard from data entitlement, because the actions an agent may take are a different question from the data it may read. Redaction and minimisation applied in line. A human approval gateway for sensitive actions. And a run ledger that the layer, not the agent, writes as a tamper-evident, exportable record of the whole run.

Underneath both runs an assurance spine: a quality evaluator that scores completeness, staleness, contradiction, and evidence sufficiency and can gate the response, degrading or forcing review rather than answering on bad ground; a drift monitor that catches a definition changing upstream; and a lifecycle manager that moves context assets through build, test, review, approve, deploy, and learn, with humans approving what goes live.

The ordering is the design

Here is the decision that separates a context layer architecture that holds from one that merely has the right boxes. The sequence on every request is fixed: the agent asks the gateway; the control plane binds identity and purpose and decides what data, tools, and context classes are allowed; the context plane then assembles, scoped by that decision, with non-entitled fields redacted before anything is returned; the quality spine flags stale or low-confidence context and can gate the response; the gateway returns a task-scoped bundle with its evidence references; the agent reasons over that bundle; sensitive actions route to a named human; and the run ledger records the lot.

Read that order carefully, because it is where good intentions leak. Policy is enforced before the agent reasons, not after it has already seen everything. A layer that assembles first and filters the response afterwards has already lost: the sensitive data was in the agent's context before the rule ran, and your audit trail now has to prove a negative. Enforce first, assemble second. That is the whole architecture compressed to four words.

Assemble-then-filter is a data leak with a nice interface. Enforce-then-assemble is a control. The boxes look identical on a slide; only the arrows differ.

One piece a box diagram tends to hide: when one agent delegates to another (increasingly common as A2A spreads), each still comes through the gateway, and the policy engine enforces the delegation chain, so an agent acting on a user's behalf cannot exceed that user's entitlements just because another agent asked. The ledger records the hand-off. Orchestrating the conversation between agents is the runtime's job; governing the authority that flows across it is this layer's.

Building it where the systems don't agree

Take a composite from a tier-1 lender. An agent has to work across three systems that were never designed to agree: a financial-crime platform, the core banking system, and a case-management system, each acquired or built at a different time, each with its own access model and its own idea of a customer identifier. The obvious way to let it work across all three is to govern the agent inside each system separately: wire it into each one and enforce identity, policy, redaction, and logging at every integration. Do that and you have built the governance three times, in three access models that drift apart as the systems change underneath them, with no single place that can say what the agent was allowed to do or what it actually did.

The context layer architecture puts the governance in one place instead. One gateway sits in front of all three systems, with one identity-and-purpose binding, one policy engine, and one ledger. The rules and the record are built once, not three times. The only per-system work is a thin connector that reads from each source, which is data plumbing you would need in any design, because the data genuinely lives in three places. On top of that, entity resolution reconciles the three customer identifiers so the agent reasons about one person rather than three disconnected records, which the per-system approach cannot deliver at all. The first connector takes longer than the team expects, because it comes with the layer; the next two are cheap. And when the risk function or an examiner asks the bank to prove what the agent did, the evidence is already in one ledger, rather than scattered across three systems for the team to pull together and reconcile after the fact.

The objection: isn't the gateway a bottleneck and a single point of failure?

The sharpest engineering counter is that a single governed door is a single point of failure and a latency tax on every call. It is a fair worry, and a design that ignored it would deserve the scepticism. Two things answer it. First, the gateway is thin and horizontally scalable precisely because it holds no state of its own: it orchestrates and enforces, and you run as many instances as you need behind a load balancer. The latency it adds should sit in the tens of milliseconds against agent calls that already take seconds. Second, and more important, the alternative to one governed door is not zero doors; it is many ungoverned ones, each its own failure mode and audit gap. Concentrating the control gives you one thing to make resilient and one thing to reason about, which in a regulated setting is a feature, not a cost. The rule is fail-closed: if the policy engine is unreachable, the safe default is to deny rather than wave the agent through.

What to do differently on Monday

If you own the build, hold the design to three tests before anyone writes a connector. Is there exactly one entry point, with no bypass and a fail-closed default? Does policy run before assembly, provably, rather than filtering the response? And does the layer write the audit record, not the agent? Sketch the request sequence on a whiteboard and put your finger on the exact step where a non-entitled field would be removed. If you cannot find it, or it sits after the agent has already seen the data, the architecture is not ready, however elegant the box diagram looks.

Where this leaves us

A context layer architecture that holds up is a single governed door, two planes, an assurance spine, and one non-negotiable ordering: enforce, then assemble, then record. Everything else is detail you can vary by enterprise. Get the ordering wrong and no amount of the right components will save you at audit.

Which raises the question a risk officer asks next: are those controls real, or just drawn? A control you cannot test is a control you do not have.

Next: why your context layer is really a control layer, and how to prove each control with a test you can re-run on demand.