Skip to content

Whitepaper · THE ACTION LAYER · Part 1

The Action Layer

Why agent infrastructure needs a fourth layer, and what it does

A. Watts··12 min·patent-pending architecture

Abstract

Autonomous AI systems need a distinct fourth infrastructure layer — separate from model, orchestration, and transport — to authorize and prove consequential actions. Without it, errors stop being outputs and become events. This paper argues the action layer is inevitable, defines the four properties it must provide, and shows why every system that lets agents act will either adopt it or become it through failure.

First published with Execution Protocol. Read the version of record ↗


Models can generate. Agents can decide. Protocols can route. None of them control what is allowed to happen. That gap is harmless while agents only produce text. It becomes the whole problem the moment they take actions with consequences — because then an error is no longer an output. It is an event.

The claim of this paper is simple: autonomous systems need a distinct fourth layer, separate from the model, the orchestration framework, and the transport protocol, whose only job is to authorize and prove consequential actions. The system that acts cannot be the system that decides whether it is allowed to act. Financial systems already work this way — the trader does not approve their own trade; the clearing house does.

Concretely, the layer takes one structured request and returns one terminal outcome with proof:

// one structured intent in →
{ "action": "flight.book",
  "constraints": { "max_usd": 500, "approver": "ops@acme.com" } }
 
// one terminal outcome out — a signed receipt →
{ "outcome": "blocked",
  "reason": "exceeds_delegation",
  "receipt": "sha256:9f2c…", "signed": true }

The four properties it must provide

01

Deterministic enforcement

The same request yields the same authorization decision every time — independent of model temperature, sampling, or timing.
02

A model-impassable boundary

Authorization happens on the structured request, not on natural language, so the model cannot talk its way past the boundary.
03

Cryptographic proof

Every outcome — executed, instructed, or blocked — produces a signed, hash-chained receipt that verifies offline.
04

Refusal as a first-class outcome

A blocked action is not an error. It is a receipt with the same cryptographic weight as one that executed.

Where the layers fit

LayerPlayersStatus
ModelOpenAI · Anthropic · Google · MetaMature
OrchestrationLangChain · LangGraph · AutoGenConverging
TransportMCP · A2A · Visa ACPStandardizing
ActionundefinedThe gap

The first three layers are real and maturing. The fourth is missing — and it is the one that decides whether an agent's action is allowed, and proves what happened.

What the action layer is not

  • Not another model, and not a smarter agent.
  • Not an orchestration framework — it constrains them, it does not replace them.
  • Not a transport protocol — it decides what is allowed, not how messages move.
  • Not application-level guardrails bolted on after the fact.

Why it is inevitable

Infrastructure does not rely on trust. It relies on guarantees. As soon as agents move money, mutate systems, or send things on someone's behalf, the questions who authorized this? and what actually happened? become non-negotiable — and a probabilistic system cannot answer them about itself. The action layer is where those guarantees have to live. Every system that lets agents act will either adopt it, or become it through failure.

Cite this

Watts, A. (2026). The Action Layer: Why agent infrastructure needs a fourth layer, and what it does. Antoni Watts. https://www.executionprotocol.dev/whitepapers/the-action-layer

Version of record ↗

DOI pending — Zenodo mint on release (see docs/concept/02_CONTENT_MODEL.md)

Antoni Watts · CC BY 4.0 · part of an ongoing research series