← Blog

The Layer That Doesn't Exist

The architectures many teams are deploying for autonomous AI systems have the same gap, and it is worth being precise about what kind of gap it is. The gap is structural rather than incidental. The gap is not a missing feature, or an immature implementation of a feature, or a feature waiting on better tooling. It is a missing layer.

However you decompose the architecture (model, tools, retrieval, memory, orchestration), the layers fall into two categories. Some generate intent: a model reasons, plans and produces structured output. Others produce consequence: connectors, adapters and protocol bridges translate that output into API calls, database writes and external messages. Each of those categories has received serious engineering investment over the past few years, and the investment shows. Model providers optimise reasoning, framework developers build sophisticated tool orchestration, and retrieval and memory architectures are active research areas.

What you often find between those two categories, when you look carefully, is no separate plane. No independent evaluation, no policy check with its own evidence. Constraints exist, including rate limits, ad hoc policies and approval workflows, but they are embedded in the execution path itself, not separated as a distinct evaluation plane. The pipeline is trusted by construction.

A trusted pipeline is still just a trusted pipeline. It has not become governance.

Current Stack Model generate intent MISSING Tool execute action Consequence external effect Trust by construction Required Stack Model generate intent Governance evaluate authority Tool execute action Consequence external effect Authority by evaluation

The missing layer: In the current stack, model output flows directly to tool execution — trusted by construction, with no independent evaluation. The required stack inserts a governance plane between model and tool, rendering an explicit authority decision before consequence occurs.

Why It Is Absent

The gap reflects the history of how these systems were built. Early tool-calling architectures were designed for demonstrations, and in a demonstration the model was the operator. If the model produced a valid tool call, the system executed it, because a human was assumed to be watching. There was no need for an independent authority check, because the human was the authority check.

As those systems moved into production, the human left the loop. But the architecture did not change. The pipeline still trusts the model’s output as implicitly authorised. The trust assumption that was originally justified by a human’s presence has been left in place after the human walked away.

The ecosystem has responded with safety mechanisms bolted onto the execution path: content filters, prompt guards, tool allowlists, soft policies enforced by the same code that calls the tool. None of those is, on its own merits, an independent evaluation plane. They constrain behaviour at points the execution path already controls. They do not evaluate whether the action is authorised.

Governance Is The Control Plane

Networking architecture draws a well-understood distinction between the control plane and the data plane. The data plane moves packets, the control plane decides where packets should go, and they are separate concerns with different failure modes and different operational requirements. Autonomous AI systems need the same separation, and many current architectures do not have it.

The execution path (model reasoning, tool invocation, API calls) is the data plane. It moves actions from intent to consequence. It is optimised for capability, latency and throughput. The governance layer is the control plane. It sits at the action boundary, the point between intent and consequence, and evaluates actions against policy before execution. Its optimisation criteria are different ones: correctness, determinism, the integrity of the evidence it produces. It does not execute actions; it decides whether actions should execute.

I have considered the alternative move, which is to push more enforcement into the execution path itself, and I have rejected it for the same reason every time. The properties that make governance meaningful cannot be bolted onto a pipeline. Evaluating before execution, rendering an explicit decision, producing tamper-evident evidence, and remaining independent of the execution path are not features that can be added to the data plane the way you might add a rate limiter or a metrics hook. They belong to a distinct architectural layer, one that does not exist in the current stack.

When the two planes are collapsed (when governance is embedded in the execution path, or when the execution path is trusted to govern itself) the system loses the ability to distinguish between “this action executed” and “this action was authorised to execute”. The two become indistinguishable. A system that cannot separate “it happened” from “it was authorised to happen” does not have governance. It has a pipeline with good intentions.

The Missing Primitive Has To Be Separate

The action boundary is not a feature to add to existing frameworks. It is an architectural primitive, a layer that must exist between intent and consequence for governance to be possible at all.

Today, that layer is often empty. Every action is implicitly authorised by the pipeline that executes it. Execution becomes its own justification. When execution becomes its own justification, the system may still be useful automation, but it is not governed autonomous action.