The Missing Layer
Why connectivity is not control, and why enterprise architecture must now govern the space between interpreted goals and contractual execution.
1. The first non-deterministic client
For the last three decades, every client reaching enterprise systems did so through a deterministic contract: screens enforced validation, batch jobs followed a scheduler, integration platforms carried typed messages along known pipelines. Even human operators, whose reasoning was in principle as non-deterministic as anyone’s, were channelled into contracted shapes by the interface in front of them. The systems on the far side were never asked to think about what anyone meant; they executed what they received.
Agents are the first clients to break that assumption. They are a new category of client altogether, one that interprets the goal on its own terms and composes the sequence of actions through its own reasoning. The fracture described in the previous article, between interpreted intent and contractual execution, is the first architectural consequence of receiving, at scale, a client that can think. When the category of client changes, the responsibilities of the architecture that serves it change with it.
2. Connectivity is not control
When the fracture starts to surface, the instinct is to treat it as a connectivity problem. Model Context Protocol standardises tool interaction. Function calling makes invocations well-typed. Tool catalogs expose what a system can do. Together they feel as though they should be enough, which is why the industry rushed toward them.
They solve the question of access, and they leave the question of governance open.
MCP defines the shape of an invocation, without saying anything about whether the invocation is acceptable in this context, for this role, at this stage of a business trajectory. Function calling guarantees that calls are syntactically valid; it guarantees nothing about whether the sequence they form makes business sense. Tool catalogs answer what is reachable, a different question from what is acceptable.
A connected agent can act. Whether it should act, here, now, for this customer, under this state of play, is a different architectural question. Connectivity cannot answer it.
3. Two execution spaces
Agents and enterprise systems operate in fundamentally different execution logics, and the difference is what makes direct translation impossible.
An agent lives in a semantic decision space. Its goals are under-specified, its planning is probabilistic, and its sense of what to do next is produced by interpretation, reshaped continuously by context. An enterprise system lives in a deterministic execution space. Inputs and outputs are schemas, state machines enforce transitions, interfaces are versioned, invariants constrain what the system is allowed to become.
These two logics do not translate directly, and no good will on either side makes them converge.
An agent produces hypotheses. The system accepts facts. Sending a hypothesis directly into a system built to accept facts is a category error.
When nothing mediates between interpretation and execution, the enterprise absorbs the gap blindly.
What follows is rarely a crash. It is a drift.
What happens in practice has a recognisable shape. The agent interprets a goal and produces a sequence of individually valid tool calls. The enterprise returns technically valid responses. In aggregate, the sequence violates a business invariant no single service was responsible for holding. The system does not crash; it drifts.
When interpretation leaks straight into execution, the consequences are rarely loud. They are subtle and hard to diagnose: technically valid but business-invalid operations, unauthorised capability drift, incoherent call sequences, hidden state corruption, recovery paths that were never designed because no one expected to need them.
The danger in agentic systems is rarely a visible failure. It is a perfectly governed set of services that, taken together, absorb an ungoverned execution pattern and look fine on every monitoring dashboard.
5. A plane, not a pipeline
When mediation is accepted as a real responsibility, the temptation is to reach for the simplest shape: one more stage in the flow, a validator between the agent and the backend. That framing is intuitive, and it costs real money.
The mediation layer does not sit in the flow; the flow happens inside it.
A more useful picture is that of a control plane with two axes. Along the trajectory, three responsibilities take turns: the plane enriches what the agent can see, then constrains what the agent may do, then validates what the agent proposes. This is the axial view.
The second axis tends to get missed. Three further responsibilities span the entire plane, without being tied to any step. Security is a pressure held throughout. Traceability is continuous. Recovery has to be a property of the plane before it can be a property of any action. These run across what the axial responsibilities produce, which is why calling them transverse makes sense.
Two axes. Six responsibilities. A plane, not a pipeline. The distinction is not semantic. It determines what the architecture can govern, and what it leaves to drift.
6. The three axial responsibilities
Enrich
The first responsibility of the plane is to decide what the agent is allowed to see.
An agent reasons on what reaches it, which in practice means the prompt and the tool catalog. That is rarely enough. The agent does not know that the customer is under active dispute, that the case falls in a retention segment, or that a regulatory hold has been applied to the account. These facts live in system state, workflow history, and policy; the plane pulls them into the decision environment before reasoning starts. Risk signals surfaced here tighten the capability filter; context assembled here shapes the invariants validation will evaluate.
Constrain
Once the context is available, the next responsibility is to filter what the agent is allowed to do.
Between the set of tools the agent sees in its catalog and the subset authorised in this specific context, there is almost always a gap. An agent may have legitimate access to both cancel_order and update_order in the general case, but in a settled contract under regulatory oversight, only one of them is an acceptable action. Visibility must never become permission automatically, even when both calls would satisfy every API contract they are sent through. A capability filter that ignores enriched context degrades to static role-based access control, which does not scale to agentic trajectories; one that does not inform validation lets the agent propose actions rejected only after work has been done.
Validate
The third axial responsibility is to evaluate the proposed trajectory against business invariants before execution starts.
A sequence of calls can satisfy every individual API contract and still be business-invalid. cancel_order followed by create_order may be syntactically unobjectionable, but in a context where update_order is the only coherent operation, the sequence is wrong regardless of whether each step, taken alone, is legal. The invariants that live on the sequence itself are what the plane validates, and in most enterprise systems those invariants are implicit, scattered across services, or absent entirely. Validation closes the axial chain, catching what enrichment did not surface and constraint did not prevent; for this to be reliable, the invariants must be declarative, testable, and held in the plane itself rather than buried inside the services that execute the calls.
7. The three transverse responsibilities
Secure
The security model of the mediation plane is continuous, not gated. Classical role-based control assumes a single authorization decision taken at the boundary of a system; agentic trajectories make that model obsolete.
Authorization becomes dynamic. General access to a tool family does not imply stable authorization across a trajectory. An agent may hold general access to customer tools but not to payment reversal beyond a threshold, and that threshold may shift mid-trajectory because of a risk signal the enrichment produced, or because a downstream event revealed a condition the original context missed. Least privilege, scoped access, risk-based escalation, human checkpointing, separation of duties: the plane holds these for the duration of the trajectory. Security consumes signals from enrichment and trace continuously; tighter integration moves authorization from static toward the contextual form agents require.
Trace
Observability tells you what happened. A decision trace tells you what was allowed to happen, and why.
The execution log and the decision trace are genuinely different artefacts, and conflating them is how organisations discover, usually too late, that they cannot explain their own systems. The log records that API X was called at timestamp T. The trace records the intent, the alternatives the plane considered, the policies applied, the path selected, the escalations triggered, and the link to the downstream events. Both streams run in parallel and stay linked, because neither is useful on its own. Trace feeds security and recovery continuously: anomalies tighten authorization in flight, and the same traces are what compensation consults to scope its action without replaying the full reasoning.
Recover
The plane has to assume the agent will sometimes be wrong. Not occasionally, not exceptionally, but predictably. Recovery is what turns that assumption into an operational reality.
Recovery covers the ability to compensate a single step without rejecting the trajectory, to open a corrective path under the same governance, to neutralise an intermediate state without downstream corruption, and to replay a partial sequence from a checkpoint. It does not raise exceptions; it emits compensating events, a subtler primitive than rollback. Recovery consumes trace and can open new governed trajectories through the plane itself, keeping recovery under governance. Without this property, the only response to an in-flight error is a manual rollback, and the trajectory becomes one-shot.
8. What this layer is not
The mediation layer is routinely confused with six adjacent concerns.
API gateway. A gateway governs traffic: routing, authentication, transformation, throttling. It does not govern the translation from intent into acceptable execution.
Workflow engine. A workflow engine executes predefined paths. The mediation layer governs paths partially generated at runtime by an agent, which is a different problem.
MCP. MCP provides technical context: which tools exist, which schemas they expose, how they are invoked. It does not decide whether a given trajectory is business-valid. MCP is potentially a component inside the mediation layer, not a competitor to it.
Prompt engineering. Prompting shapes how a model speaks. The mediation layer shapes how a system behaves. Better prompts may reduce ambiguity in model output, but they do not produce architectural guarantees in system execution.
Model-level guardrails. Guardrails constrain what the model says. The mediation layer constrains what the system does. Two different stacks, two different governance regimes.
Policy engine in isolation. A policy engine evaluates rules against structured inputs. It does not resolve context, validate multi-step invariants, compose trajectories, or compensate deviations. A policy engine is a component; the plane is a responsibility set.
9. Intent as hypothesis, event as fact
There is a cleaner way to read the mediation layer, and it comes from event-driven architecture rather than from the domain of agents.
An intent is a hypothesis the agent formulates about what the business should do; an event is a fact the business has recorded. The mediation layer turns the first into something capable of producing the second. Read this way, the layer becomes an intent-to-event compiler, and the consequences of that framing are not cosmetic.
The agent does not call a system directly. It proposes a candidate command, which is enriched and validated by the plane before it touches anything. Execution then emits an event, which becomes the new ground truth. The business does not trust what the agent meant; it trusts what the system recorded. This is the asymmetry the layer preserves: intents remain hypotheses, events become contract.
Once that picture is in place, reconciliation stops being a batch job and becomes a continuous function of the plane. As events start flowing, the plane compares what was produced against what was intended. Was the trajectory actually satisfied? Was an invariant violated after the fact? Did a downstream event reveal that an earlier step was based on stale context? These are questions answered in the loop, not in an end-of-day report. Compensation gains a native vocabulary too: the plane does not roll back (rollback would hide history); it emits compensating events, which acknowledge that something happened and declare what is being done to restore coherence.
One clarification for readers who live in event-sourced systems: this is not event sourcing. Event sourcing reconstructs state from an immutable log; the mediation layer uses events as the contract surface between agent reasoning and enterprise execution. The two are compatible, often used together, but they do different jobs.
In agentic architectures, events remain the contract. Intents never will be.
10. A composite case: the payment exception
A customer disputes a double charge that also affected their payment plan. Six operations follow: identify the charges, issue a partial refund, adjust the payment plan, suspend the dunning process, notify the customer, and update the risk scoring. Each maps to a valid API. No individual call is unauthorised in principle, and the difficulty is not in any single action.
Without the layer. The agent interprets the goal and selects a technically valid sequence.
Each call passes its own contract. The sequence violates a business invariant: the refund is issued before the dunning process is suspended, and a collection notice reaches a customer whose dispute was already being resolved. The inconsistency surfaces later, as a customer complaint or a reconciliation exception, and root cause analysis identifies no single failure because every step was technically valid when it ran.
With the layer. The intent is enriched with an active dispute flag, a retention segment marker, and the observation that the refund exceeds the authorization threshold. Capabilities are filtered on the enriched context; the refund above threshold escalates to a human gate. The trajectory is validated against the invariant that suspension must precede refund, and is either reordered by the plane or rejected with a correction returned to the agent. Each step emits an event, and the decision trace links intent, policy, command, and event in a reasoning-to-fact chain auditable end to end.
Mid-trajectory. At step three, adjusting the payment plan, the resulting event surfaces a detail the enrichment missed: a co-signer is bound to the same plan, and adjusting it triggers a notification obligation the agent did not model. Without the plane, the notification reaches the co-signer with information inconsistent with the refund already issued. With the plane, the event is reconciled in flight. The Compensation Manager issues a targeted compensation on step two alone, partially reversing the refund to realign it with the adjusted plan, while a corrective trajectory is opened and governed from scratch to handle the co-signer notification. Steps one and three are preserved. The agent does not replay its full reasoning.
What the plane buys is the difference between an incident that surfaces later as a customer complaint and one that surfaces in the trace as a compensated deviation. The problem is never a single action; it is the trajectory those actions compose.
11. A minimal reference architecture
Holding the plane coherently requires six components, one per responsibility, plus two transverse extensions that sit alongside the axial chain rather than on it.
Intent Intake receives the interpreted goal from the agent and normalises it. Context Resolver assembles the enriched context from system state, workflow history, and policy inputs. Capability Policy Engine filters visible tools to contextually authorised capabilities. Business Invariant Validator evaluates candidate trajectories against the declarative invariants held in the plane. Governed Orchestrator issues commands to the enterprise systems and holds security as a continuous condition rather than a gate. Compensation Manager listens to the resulting events, detects deviations, and emits compensating commands through the same intake, under the same governance as the original trajectory.
Two transverse extensions complete the picture: a Trace and Audit Layer that records decisions and not only executions, and a Human Oversight Point that receives escalations when risk thresholds or policy exceptions trigger a hand-off.
Intent Intake hands the goal to Context Resolver, which enriches and forwards in parallel to the Capability Policy Engine and the Invariant Validator; neither does its job on partial context. The Orchestrator executes the validated trajectory and emits events consumed by both the Compensation Manager and the Trace and Audit Layer. The Compensation Manager opens new governed trajectories through the same Intake, keeping the plane closed under recovery.
This is a responsibility architecture, not a deployment prescription. In small domains, the six components may collapse into a single runtime. In enterprise-scale systems they will be distributed. The shape of the responsibilities, not of the deployment, is what decides whether the plane is coherent.
12. An expanded mandate for enterprise architecture
Classical enterprise architecture governed the interfaces between deterministic systems. It owned contracts between services, boundaries between domains, flows between layers, control surfaces between zones, all of them operating between systems that could not reason on their own. The client was always outside the frame, and it was always assumed to submit what the architecture expected.
The agentic era does not replace that mandate; it extends it. The design perimeter now includes the translation from interpretation into acceptable execution. The artefacts enterprise architecture owns expand: capability policies, invariant specifications, decision trace schemas. Risk categories expand too, with semantic drift joining availability and integrity as first-class concerns. Explainability of decisions becomes as operationally necessary as observability of events.
This competence does not live cleanly inside any existing team. It crosses enterprise architecture, platform engineering, security, and whatever the organisation calls its AI platform group. Organisations that leave ownership unassigned end up with a mediation layer distributed across services, stitched together by prompts, and impossible to govern.
13. Maturity signals: do you already have this layer?
The mediation layer is observable mostly by its absence. The symptoms a system produces when it is implicit, distributed, or missing are reliable enough to diagnose it without opening the code.
Six questions tend to be sufficient.
1. Do your agents expose the same tool catalog regardless of the business context of the request? If yes, the constraint responsibility is absent. Visibility has become permission.
2. Do your execution logs record what was done but not which trajectories were considered and rejected? If yes, observability is in place but decision trace is not. The system is monitored without being explainable.
3. Do your invariant checks live inside individual services rather than on the sequence they form? If yes, validation is distributed to services that cannot see the full trajectory. Technical validity governs where business coherence should.
4. Does your agent governance rely primarily on prompts, system messages, or guardrails? If yes, governance has been delegated to the model. The system has no architectural defence when the model drifts.
5. Can you reconstruct why an agent chose one action over another at a given moment? If not, decision trace either does not exist or is not linked to policy and context. Monitoring audits pass; governance reviews do not.
6. When an error occurs mid-trajectory, is your only response a manual human rollback? If yes, recovery is not a property of the plane. The trajectory is one-shot, which is expensive to operate.
One or two affirmatives: the layer exists partially, as local patterns to consolidate. Three or four: it is implicit and distributed, fragmented rather than held as a reasoned responsibility. Five or six: it does not exist architecturally, worse than absence because its functions have been absorbed into the agent and the services and can no longer be reasoned about.
The plane is detected by the symptoms of its absence, not by its presence.
14. The next move
The mediation layer is not a component to install, a product to buy, or an adapter to slot in somewhere. It takes the form of a control plane with a defined set of responsibilities, three that shape the trajectory and three that span it, and it is missing from most enterprise architectures for a simple historical reason: it was never needed in a deterministic world.
To design this plane consistently across domains and organisations, the responsibilities must be named, the patterns typed, the maturity criteria made explicit, the trajectories rendered canonical. Naming them once is not enough. Typing them properly is the work of a framework, which is the object of the next article.
Once the layer becomes visible as the new control surface of the enterprise, the question is no longer whether it exists, but whether it is being designed deliberately or absorbed blindly by the system around it.
