Protocol landscape
The agent ecosystem has several emerging protocols. They are not competitors of Execution Protocol — they cover different layers of the stack. Most production agents use several of them together.
The five layers
Application
Google UCP · Visa VIC
Transaction
Execution Protocol
Communication
Google A2A · AP2 · OpenAI ACP
Payment
Visa TAP · Mastercard AP
Data
MCP (Anthropic)
Each layer answers a different question:
- Application — what's the user-facing flow? (book a flight, place an order)
- Transaction — how does the action commit safely? (Execution Protocol)
- Communication — how do two agents talk to each other? (A2A, ACP)
- Payment — how do we move money? (TAP, AP)
- Data — how does an agent see the world? (MCP)
Native protocol primitives
This table compares what each protocol specifies as a primitive, not what you can build on top. Anyone can wrap a REST API in middleware that signs responses or enforces policy — that doesn't make signing or policy a REST primitive. The honest question is: when you adopt this protocol, what does the protocol itself specify and guarantee?
| Capability | Execution | A2A | MCP | ACP | REST |
|---|---|---|---|---|---|
| Pre-commit policy primitive | ✓ | not in scope | not in scope | not in scope | not in scope |
| Signed-receipt primitive | ✓ | not in scope | not in scope | not in scope | not in scope |
| Scoped-delegation primitive | ✓ | partial — auth/identity | not in scope | partial | not in scope |
| Hash-chain audit primitive | ✓ | not in scope | not in scope | not in scope | not in scope |
| Tool-discovery primitive | not in scope | not in scope | ✓ | ✓ | not in scope |
| Multi-agent-communication primitive | not in scope | ✓ | not in scope | ✓ | not in scope |
| Stateless-request constraint | ✓ | not in scope | not in scope | not in scope | ✓ |
"not in scope" ≠ "impossible." Of course you can sign HTTP responses or enforce policy in REST middleware. The question this table answers is what the protocol itself specifies as a primitive vs. what you can layer on top.
Execution Protocol's scope is the action-commitment surface: pre-commit policy, signed receipts, scoped delegation, hash-chain audit, stateless requests. It is not a multi-agent communication protocol — that's A2A's territory. It is not a tool-context protocol — that's MCP's territory.
When to use which
| You need to | Use |
|---|---|
| Execute a transaction with proof and policy | Execution Protocol |
| Pass tool context to a model | MCP |
| Coordinate two agents | A2A or ACP |
| Move money | TAP, AP, or your existing PSP |
| Build the user-facing app | UCP, VIC, or your own UI |
A common production stack looks like:
agent
│
│ uses MCP to load tool context
│ uses A2A to coordinate with other agents
│ uses Execution Protocol to commit actions safely
│ uses TAP to move money on commit
▼
real-world action
Why the layers stay separate
Bundling them creates tight coupling. The discovery layer changes more often than the transaction layer. The communication layer iterates on protocols that the transaction layer should be agnostic to. By keeping Execution Protocol focused on "intent → committed action with proof," we let MCP / A2A / ACP evolve without breaking action-commitment guarantees.
See also
- How it works — the deterministic pipeline.
- Architecture — internals.
- Comparison table on the homepage — feature presence at a glance.