The history of distributed computing is one of protocol proliferation followed by consolidation.
Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Java Remote Method Invocation (RMI), and early 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 HTTP-native.
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. Each new computing paradigm generates an explosion of competing standards, then gradually converges as implementation and interoperability become economically necessary.
The AI agent ecosystem is currently in the proliferation phase. Four significant protocols have been published in the last eighteen months: Model Reference Protocol (MCP) from Anthropic in late 2024, Agent Communication Protocol (ACP) from IBM Research in March 2025, Agent2Agent (A2A) from Google in April 2025, and Agent Network Protocol (ANP) from an independent working group.
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. The conferences are running workshops on interoperability. Every week brings a new GitHub repository claiming to solve the agent communication problem.
Understanding where and how fast this convergence occurs has real consequences for the architectural decisions being made now.
What do protocols actually solve?
The proliferation looks more chaotic than it is, because most of these protocols address different layers of the stack rather than competing for the same slot. The confusion comes from marketing, which describes each as "Standards for AI Agent Communication" Without specifying which aspect of communication.
MCP is a tool-calling interface. It defines how a model figures out what actions the server exposes, how to invoke them, and how to interpret the response. It is a typed remote procedure call (RPC) contract running over HTTP between a model client and a tool server. The Linux Foundation confirmed more than 10,000 active public MCP servers and 164 million monthly Python SDK downloads by April 2026. MCP has already won the tool-calling layer. Standardization work has been done effectively.
A2A is a task coordination interface. Where MCP defines how an agent calls a tool, A2A defines how two agents delegate a task. It offers agent cards (capability ads), 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. This is useful in systems where simple messaging is sufficient and the task lifecycle overhead of A2A is unnecessary.
ANP is a discovery and identification protocol. It uses decentralized identifiers (DIDs) for agent identification and JSON-LD graphs for capability descriptions, providing a foundation for decentralized agent markets where no central registry is required.
The stack that is emerging is: capability discovery via ANP or simple registries, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP for those cases that do not require full task lifecycle management. These layers complement rather than compete.
The problem of transportation remains
Every protocol on this list runs on HTTP. This reflects where the protocols came from: research teams, API providers, and enterprise software companies building systems where HTTP is an unquestioned notion. HTTP is the protocol they know, the one their servers already speak, and the one that makes demos easier.
The production problem is that HTTP assumes an unreachable server. Behind Network Address Translation (NAT) – and 88% of network devices sit behind NAT – there are no reachable servers without relays. 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 failure modes.
Application-layer protocols resolve the semantics of what agents say to each other. They do not solve how agents find each other and establish connections directly. This is a session-layer problem, layer 5 in the Open Systems Interconnection (OSI) model, and none of MCP, A2A, ACP, or ANP addresses it.
There are techniques to solve this. UDP hole-punching with session traversal utilities for NAT (STUN) provides NAT traversal for about 70% of network topologies. X25519 Diffie-Hellman and AES-256-GCM provide authenticated encryption at the tunnel level without certificate authority. Custom sliding-window protocols over Quick UDP Internet Connection (QUIC) (RFC 9000) or User Datagram Protocol (UDP) provide reliable delivery without TCP’s head-of-line blocking. These are the same primitives that WireGuard uses for VPN tunnels and WebRTC uses for browser-to-browser media streams.
What differs in the agent context is capability-based routing. Agents must find peers not by hostname, but by what those peers can do. A research agent must be able to interrogate "Which partners have real-time Forex data?" And get a list of currently active expert agents. It is closer to a service registry than to DNS, and is a natural extension of the design philosophy of ANP applied to the transport layer.
A handful of projects are putting together these pieces. The pilot protocol has the most complete published specification with the IETF Internet-Draft, including addressing, tunnel establishment, and NAT traversal for agent networks. libp2p provides a battle-tested base with similar primitives. The IETF’s QUIC working group is developing NAT traversal extensions that would be relevant here.
what convergence will look like
HTTP-based protocols (MCP, A2A) are already transitioning to stable versions. The next 12 months will see production consolidation, security improvements, stateless MCP servers for horizontal scaling, better A2A federation rather than new radical designs. The tool-calling and task-coordination layers are largely resolved.
The transport layer is 18 to 24 months behind. Expect a period of implementation diversity as teams experiment with different approaches to peer-to-peer (P2P) agent networking, followed by consolidation around a small number of implementations as empirical data on performance and reliability accumulate. The IETF and W3C standardization tracks will likely produce something in the 2027–2028 window, by which time one or two open-source implementations will have accrued 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 build upon. Adopting MCP is now less risky. Adoption of A2A for multi-agent coordination is justified with the expectation that the protocol will evolve. The transport layer is where you either build something custom and plan to change it, or you evaluate the initial implementation knowing that the space will still be moving.
The teams that will benefit most when the transport layer is stable are those that have designed their agent systems with a clear separation between application semantics (MCP, A2A) and the transport (whatever sits underneath). Clean separation is cheap to implement now and expensive to retrofit later, a lesson taught to anyone in the microservices era who tried to add observability or circuit breaking to systems that had none.
Philip Staetsky is the co-founder of Vulture Labs.
<a href