New paperGrounding Promises in the Sandbox: an environment-grounded commitment protocol for trained autonomous agents.Read now
All posts
Engineering

The protocol shake-out: what to actually build on in 2026

MCP, A2A, ACP, ANP, and a half-dozen commerce protocols. You don't have to bet on a winner — you have to understand which layer each one occupies.

Teleperson Team · May 11, 2026 · 4 min read

If you are building anything agentic this year, you have run into the protocol question, and you have probably run into it as anxiety: there are too many standards, they seem to overlap, and picking wrong feels like it could strand you.

The anxiety is misplaced — but the fix is not "wait for a winner." It's to stop reading the protocol landscape as a single race. It isn't one race. It's several, on different tracks, and most of the apparent competition is an artifact of flattening them onto one map.

The protocols occupy different layers

Sort the major standards by the layer of the stack they actually address and the overlap mostly dissolves.

  • Agent-to-tool. The Model Context Protocol (MCP) standardizes how an agent connects to external tools and data. It is, in practice, the settled answer for this layer — broad adoption, clear remit. If your agent needs to call tools, you build against MCP and you do not spend a meeting agonizing about it.
  • Agent-to-agent transport. Google's A2A protocol defines how two agents discover and talk to each other across platforms — agent cards, a task lifecycle, streaming. The Agent Communication Protocol (ACP) is a REST-native take on the same layer; the Agent Network Protocol (ANP) targets fully decentralized, peer-to-peer discovery. These three genuinely compete, because they are answering the same question with different assumptions.
  • Commerce vocabulary. A separate cluster — agentic-commerce protocols from the large model labs and the card networks — addresses how a transaction is expressed between agents: offers, terms, settlement. This layer is the least settled and the most strategically contested.

A team that says "we don't know which protocol to pick" is almost always conflating these layers. You are not choosing one protocol. You are choosing one per layer, and at least the bottom layer is already decided for you.

What's actually settled, and what isn't

The honest read, layer by layer:

The tool layer is done. Build on MCP.

The transport layer is consolidating but not closed. A2A has the most momentum and the most institutional weight behind it; ACP and ANP are real but serve narrower assumptions. This is the layer where a thin abstraction earns its keep — see below.

The commerce layer is wide open, and you should expect it to stay contested through 2026 and beyond, because whoever defines how agentic transactions are expressed sits in an extraordinarily valuable position. Do not build deep dependencies here yet. We surveyed the full field — including who is positioned where — in Agent-to-Agent Protocols: A Comparative Survey.

The practical posture: bridge, don't bet

Here is the actionable part. For any layer that isn't settled, do not hard-wire a protocol into your core logic. Put a thin internal abstraction between your agent and the wire format. Your agent reasons in your own task and capability vocabulary; an adapter translates that to A2A, or ACP, or whatever a given counterparty speaks.

This sounds like ordinary good engineering, and it is — but there's a specific reason it matters more here than usual. Bridging between protocols is not free, and it is not lossless. A task expressed in one protocol and translated into another can quietly lose a conditional, flatten a typed fault, or distort an authority scope — and nothing in a naive gateway records that it happened. We worked through exactly when a cross-protocol bridge preserves meaning, and when it provably cannot, in Lost in Translation.

The takeaway for a builder: an abstraction layer is the right call, but build it to declare what it drops. A bridge that says "I do not preserve feature X across this boundary" is safe to depend on. A bridge that silently lowest-common-denominators everything is a source of bugs you will not be able to see.

What this means for the roadmap

You do not need to predict the protocol winners. You need three things: build on MCP at the tool layer without hesitation; keep the transport layer behind an adapter so an A2A-vs-ACP shift is a contained change; and stay shallow at the commerce layer until it settles.

The teams that get hurt in a standards shake-out are the ones who picked early and wired deep. The teams that are fine are the ones who treated the protocol as a detail at the edge of the system — which, if you build it right, is exactly what it is.