The history of distributed computing is one of protocol proliferation followed by consolidation.
The Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Java Remote Method Invocation (RMI), and Simple Object Access Protocol (SOAP) competed for the enterprise integration market in the late 1990s before Representational State Transfer (REST) quietly won by being simpler and native to HTTP.
Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), and a dozen proprietary protocols fragmented real-time messaging before MG telemetry transport (MQTT) and WebSockets created their respective niches. Each new computing paradigm creates an explosion of competing standards and then slowly converges as implementations accumulate and interoperability becomes economically necessary.
The ecosystem of AI agents is currently in the proliferation phase. Four major protocols have been published in the past eighteen months: Anthropic’s Model Context Protocol (MCP) in late 2024, IBM Research’s Agent Communication Protocol (ACP) in March 2025, Google’s Agent2Agent (A2A) in April 2025, and an independent working group’s Agent Network Protocol (ANP).
The W3C AI Agent Protocol Community Group has opened a standards track. The Internet Engineering Task Force (IETF) is receiving Internet drafts on agent transport. Conferences are hosting workshops on interoperability. Every week a new GitHub repository appears that aims to solve the agent communication problem.
Understanding where and how quickly this converges has real implications for the architectural decisions being made right now.
What the protocols really solve
The proliferation seems more chaotic than it is, because most of these protocols address different layers of a stack rather than competing for the same slot. The confusion comes from marketing, which describes each as "the standard for AI agent communication" without specifying what aspect of the communication.
MCP is a tool calling interface. Defines how a model discovers what functions a server exposes, how to invoke them, and how to interpret the response. It is a remote procedure call (RPC) contract written between a model client and a tool server, running over HTTP. The Linux Foundation confirmed more than 10,000 active public MCP servers and 164 million monthly downloads of the Python SDK by April 2026. MCP has already won the tool calling layer. Standardization work is done effectively.
A2A is a task coordination interface. While MCP defines how one agent calls a tool, A2A defines how two agents delegate a task. It features agent cards (capability announcements), task lifecycle states, and three interaction modes: synchronous, streaming, and asynchronous. Google donated it to the Linux Foundation in June 2025 and it has been widely adopted by enterprise AI teams because it fills a real gap that MCP leaves open.
ACP is a message envelope format. Lightweight, stateless, designed for agent-to-agent message exchange without the full coordination semantics of A2A. It is useful in systems where simple message passing is sufficient and the lifecycle overhead of A2A tasks is unnecessary.
ANP is an identity and discovery protocol. It uses decentralized identifiers (DIDs) for agent identity and JSON-LD graphs for capability descriptions, providing a foundation for decentralized agent marketplaces where a central registry is not required.
The stack that is emerging: capability discovery via ANP or simpler registries, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP for cases that do not require full task lifecycle management. These layers complement each other rather than compete.
The transportation problem that persists
All of the protocols on this list run over HTTP. This reflects where protocols come from: research teams, API providers, and enterprise software companies building systems where HTTP is an unquestioned assumption. HTTP is the protocol they know, the one their servers already use, and the one that makes demos easy.
The production problem is that HTTP assumes an accessible server. Behind Network Address Translation (NAT), and 88% of network devices are behind NAT, there is no server accessible without a relay. For agent fleets that need to route tasks directly between peers across cloud boundaries, home networks, and edge deployments, this centralization forces each message through a relay infrastructure. Relay infrastructure adds latency, cost, and a failure mode.
Application layer protocols resolve the semantics of what agents say to each other. They do not resolve how agents find each other and establish direct connections. That’s a session layer problem, Layer 5 in the Open Systems Interconnection (OSI) model, and none of MCP, A2A, ACP, or ANP addresses it.
The technologies to solve it exist. UDP Pierce with Session Traversal Utilities for NAT (STUN) provides NAT traversal for approximately 70% of network topologies. X25519 Diffie-Hellman and AES-256-GCM provide tunnel-level authenticated encryption without a certificate authority. UDP Fast Internet Connections (QUIC) (RFC 9000) or custom sliding window protocols over User Datagram Protocol (UDP) provide reliable delivery without TCP line header blocking. These are the same primitives that WireGuard uses for VPN tunnels and that WebRTC uses for browser-to-browser media streams.
What differs in the agent context is capabilities-based routing. Agents need to find peers not by hostname but by what those peers can do. An investigation agent should be able to consult "Which pairs have real-time exchange data?" and receive a list of currently active specialist agents. This is closer to a service registry than a DNS, and is a natural extension of the ANP design philosophy applied to the transport layer.
A handful of projects are putting these pieces together. Pilot Protocol has the most complete published specification, with an IETF Internet Draft covering addressing, tunneling, and NAT traversal for agent networks. libp2p provides a battle-tested foundation with similar primitives. The IETF QUIC working group is developing cross-cutting extensions to NAT that will be relevant here.
What will convergence be like?
HTTP-based protocols (MCP, A2A) are already converging into stable versions. In the next 12 months we will see a strengthening of production, security improvements, stateless MCP servers for horizontal scaling and better A2A federation, rather than fundamental new designs. The tool calling and task coordination layers are largely resolved.
The transport layer has a delay of 18 to 24 months. Expect a period of deployment diversity as teams experiment with different approaches to peer-to-peer (P2P) agent networking, followed by consolidation around a small number of deployments once empirical data on performance and reliability accumulates. The IETF and W3C standardization pathways will likely produce something in the 2027-2028 window, by which time one or two open source implementations will have accumulated enough production deployments to establish de facto standards before formal specification.
For engineering leaders making architectural decisions today, the practical implication is layered adoption. Application layer protocols are stable enough to take advantage of. MCP adoption is now low risk. Adopting A2A for multi-agent coordination is reasonable with the expectation that the protocol will evolve. The transport layer is where you build something custom and plan to replace it, or evaluate early implementations knowing that space is still moving.
The teams that will have the most influence when the transport layer stabilizes are those that designed their agent systems with a clear separation between application semantics (MCP, A2A) and transport (whatever lies beneath). Clean separation is cheap to implement now and expensive to modernize in the future, a lesson that the microservices era taught anyone trying to add observability or circuit breaking to systems that didn’t have it.
Philip Stayetski is co-founder of Vulture Labs.
