MCP, A2A, ACP, AP2: the agent protocol stack

Every few weeks someone publishes a piece asking which agent protocol will win. MCP or A2A. ACP or AP2. It is the wrong question, and it produces the wrong roadmap.

They are layers. A single agent purchase can touch all four: the agent reaches tools and catalogue through MCP, coordinates with another organisation's agent over A2A, carries an AP2 mandate proving a human authorised the spend, and completes the order through ACP. Asking which one wins is like asking whether HTTP will beat TLS.

What did happen in the last twelve months is more interesting than a protocol war, and almost nobody has written about it: the whole layer moved into neutral governance, unusually fast, and the companies that built these specs gave them away on purpose.

1. The four layers, in one table

Two more sit at the edges. Google's UCP overlaps ACP on commerce, which is where the genuine competition is. And x402 and similar schemes handle machine to machine payment, where the buyer is not a person at all and the mandate model does not apply.

The composition is the part worth internalising. AP2 proves consent. ACP moves the order. They are frequently described as rivals and they are not: an agent can prove authorisation with a signed mandate and then complete checkout through a commerce protocol, and in the reference flows that is exactly what happens.

2. What actually happened: the layer went neutral

Here is the sequence, because the dates tell the story better than any analysis.

Google handed A2A to the Linux Foundation on 23 June 2025. OpenAI and Stripe launched ACP on 29 September 2025, with Etsy as the first integrated merchant. Google announced AP2 on 16 September 2025 with more than sixty launch partners, Mastercard, PayPal, American Express, Adyen, Coinbase, Worldpay, Revolut and Intuit among them. In December 2025 the Linux Foundation formed the Agentic AI Foundation with six co founders, OpenAI, Anthropic, Google, Microsoft, AWS and Block, taking Anthropic's MCP, Block's goose and OpenAI's AGENTS.md as founding contributions. Google donated AP2 version 0.2 to the FIDO Alliance on 28 April 2026. A2A became a hosted Agentic AI Foundation project on 17 August 2026.

Fourteen months, and the entire agent interoperability layer went from four vendor controlled specifications to neutral foundations with the six largest players sitting on the same board.

That is not generosity. It is the same logic we traced in the Kimi K3 note: you give away the layer you cannot own, so that the layer you do own gets bigger. None of these companies makes money selling a protocol. They make money on models, cloud and payment volume, all of which grow when agents can reach more systems. Handing the spec to a foundation removes the last reason a competitor would refuse to adopt it.

For a business the practical consequence is the one that matters: the adoption risk dropped. Building against a specification governed by the Linux Foundation with six backers is a materially different bet from building against one company's API that could be deprecated in a product reshuffle.

3. Start with MCP, and know what you are trusting

If you implement one thing, implement MCP. It is the layer that makes your own systems reachable by an agent at all, it has the widest adoption, and everything above it assumes it. A2A only earns its place when agents from different organisations genuinely need to coordinate, which is rarer than the diagrams suggest.

But be clear about what connecting an MCP server actually is. It is not adding an integration. It is granting something a position inside your agent's context, with the ability to shape what the agent reads and therefore what it does. CVE-2025-6514, the command injection flaw in the mcp-remote package scored 9.6, was a malicious server compromising the client. That whole failure class, and the controls that contain it, is the subject of the agent security paper. The short version: pin versions, review what you connect, sandbox the runtime, put an egress allowlist in front of it.

A protocol being open and well governed says nothing about whether the server on the other end is honest.

4. What a merchant actually has to build

Strip away the protocol politics and a business that sells things faces three questions.

Can an agent read your catalogue? Not your website, your catalogue. Real availability, real price, real variant data, in a form a machine can consume without scraping a rendered page. Most retailers discover their product data is not good enough the moment something non human tries to use it, which is a data quality project wearing an AI costume. We went through the same problem from the content side in catalog enrichment.

Do you keep checkout or delegate it? Delegating to a commerce protocol is faster to launch and hands the buying experience, and a slice of the relationship, to whoever owns the surface. Keeping your own rails and accepting a signed mandate is more work and keeps the customer. This is a commercial decision that gets made by default if nobody makes it deliberately, which is the outcome we would most like to warn against. The wider shape of that shift is the subject of retail agentic commerce, and what it does to the buying interface is in the shopping assistant.

Who owns a dispute on an order no human clicked? This is the box everybody skips. If an agent buys the wrong thing, the chargeback, the refund and the liability question all still land on a person. AP2's mandate model exists precisely to make consent provable after the fact, which is why the authorisation layer got donated to the FIDO Alliance rather than left with a cloud vendor: this is identity infrastructure, and it will be argued about by banks and regulators, not by engineers.

5. What we would do in the next quarter

Four steps, and none of them require betting on a winner.

1. Expose your systems over MCP, starting with read access to the data an agent would need to be useful. This is the highest value, lowest regret move on the list.
2. Fix the catalogue before the protocol. No commerce protocol rescues bad product data, and every one of them exposes it.
3. Make the checkout decision explicitly, with the customer relationship question on the table rather than left to whoever ships first.
4. Write down the dispute path for an agent initiated order before you accept one.

And treat A2A as a later problem unless you already have agents from different organisations that need to negotiate. The single agent case, with good tools and clear authority, covers most of what businesses actually want, and the governance discipline that keeps it safe is the subject of Governed autonomy.

The protocols settling down is genuinely good news. It means the interoperability question has an answer, and the work moves back to where it always was: whether your data is good, whether your systems are reachable, and whether a person is accountable for what the agent did. If you want that built properly, talk to us, or see how we build systems for businesses.

6. Sources

1. Model Context Protocol, the specification and reference implementations.
2. A2A protocol, the agent to agent specification.
3. Agent Payments Protocol and the FIDO Alliance, which now stewards it.
4. Agentic Commerce Protocol, from OpenAI and Stripe.
5. Linux Foundation, formation of the Agentic AI Foundation, December 2025, for the founding contributions and co founders.
6. GitHub advisory for CVE-2025-6514, for the mcp-remote vulnerability referenced above.

Protocol versions and governance in this area are moving quickly and everything here is current at 1 September 2026. Check the specification sites directly before an implementation decision, since the reference flows change between versions.

This paper sits in our Engineering track. Related work runs through the agentic, commerce and protocol spec threads, and the full library is at Research.