Infrastructure
The Protocols the Agentic Web Runs On
Three protocols, three layers, one common misunderstanding.
Three protocol names come up constantly in discussions of agent infrastructure, usually as though they were alternatives. They are not. They sit at three different layers and solve three different problems, and most of the confusion in this area comes from treating them as competing products rather than as a stack.
| Question it answers | Between | |
|---|---|---|
| MCP | How does a model use a tool it was not built against? | One agent and its tools |
| A2A | How do two agents discover each other and delegate work? | Two agents, often two organisations |
| x402 | How does a caller pay for a request, mid-request? | Any client and any paid resource |
MCP - tool access
The Model Context Protocol standardises how an agent discovers and calls capabilities: tools it can invoke, resources it can read, prompts it can reuse. A server describes what it offers; a client connects and uses it without either side having been written against the other.
Its significance is not technical elegance but the elimination of an integration matrix. Before, every combination of agent framework and external system was bespoke work. After, a system exposes one interface and any compliant agent can use it. That is the same shift that made language server tooling ubiquitous in editors, and it happened for the same reason.
What it does not do: authorisation beyond ordinary transport-level authentication, identity of the calling agent, or payment. It assumes the connection is already trusted, which is appropriate for the layer and misunderstood constantly.
A2A - agent-to-agent
Where MCP connects an agent to its tools, agent-to-agent protocols connect an agent to another agent. The problems are genuinely different: a tool is passive and returns a result, whereas another agent is an opaque counterparty that may take a long time, ask clarifying questions, or decline.
The design elements that recur across proposals: a published capability description so an agent can be discovered by what it can do; long-running task semantics with status updates rather than request-and-response; and opacity by design, so neither side has to expose its internal reasoning, tools or data.
That last property is what makes cross-organisational delegation plausible at all. A company will let its agent hand a task to a supplier's agent; it will not expose its internal tool surface to do so.
What it does not do: establish whether the other agent is who it claims to be or is authorised to act. That is a separate layer - see agent identity - and it is the thinnest part of the stack today.
x402 - payment as part of the request
HTTP reserved status code 402, "Payment Required", in 1997 and left it unused for a quarter of a century because there was no settlement mechanism cheap enough to justify it. x402 revives it: a resource responds 402 with the price and how to pay, the client settles and retries with proof, the resource is served.
The consequence is that a paid API stops needing an account, a key, a signup or a session. An agent can pay a service it has never encountered and will never encounter again, in the middle of a request, for a fraction of a cent. That property is what makes metered access a plausible business model for the agentic web, as discussed in how agents change the internet.
What it does not do: disputes or refunds. Payment is final. That is acceptable at a tenth of a cent and unacceptable above some threshold each participant has to set for themselves - the full picture on agent payments.
How they compose
A realistic request path through all three:
- Delegation A user grants an agent a scoped mandate. Not one of these three protocols - an identity-layer concern, and the layer everything else assumes.
- Discovery The agent finds a counterparty that can do what it needs, via an A2A capability description or an MCP server listing.
- Access It connects over MCP for tools, or A2A for delegated work.
- Payment The resource responds 402; the agent settles and retries with proof.
- Record Both sides keep enough evidence to reconstruct who authorised what. Also not one of these protocols - and the most commonly skipped step.
Two of the five steps in that path are not covered by any of the three protocols, and they are the two that matter when something goes wrong. The agentic web has excellent plumbing for capability and payment, and almost none for authority and evidence.
How to read protocol announcements
A field this early produces a new protocol most months. Three questions separate the ones worth reading:
- Which layer? Tool access, agent messaging, identity, payment or evidence. A proposal that claims all five is a framework, not a protocol.
- What does it assume is already trusted? Every protocol here assumes something. Knowing what it assumes tells you what you still have to build.
- Who runs the registry? Discovery mechanisms tend to require a directory, and whoever operates it acquires the gatekeeping power the protocol was supposed to remove.
Where this fits in the wider picture is on the Web4 page; what it enables commercially is in autonomous commerce.