The history of distributed computing is the history of the proliferation of protocols followed by consolidation.
Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Java remote method invocation (RMI), and the early Simple Object Access Protocol (SOAP) competed for the enterprise integration market in the late 1990s, before representational state transfer (REST) quietly won, 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 carved out their niches. Each new computing paradigm spawns a flurry of competing standards, then slowly converges as implementations accumulate and interoperability becomes economically necessary.
The ecosystem of artificial intelligence agents is now in a proliferating stage. Four major protocols have been published in the last 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 the 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) receives Internet drafts on transport agents. At the conferences, compatibility workshops are held. Every week there is a new GitHub repository that claims to solve the agent communication problem.
Understanding where and how quickly this is converging has real implications for architectural decisions being made right now.
What protocols actually decide
The distribution looks more chaotic than it is because most of these protocols are addressing different layers of the stack rather than competing for the same slot. The confusion comes from marketing describing each how "a communication standard for artificial intelligence agents" without specifying which aspect of communication.
MCP is a tool calling interface. It defines how the model discovers what functions the server exposes, how to call them, and how to interpret the response. It is a typed remote procedure call (RPC) contract between a model client and a tool server running over HTTP. The Linux Foundation has confirmed more than 10,000 active public MCP servers and 164 million Python SDK downloads per month through April 2026. MCP has already won at the instrument challenge level. Work on standardization is carried out effectively.
A2A is a task coordination interface. Where MCP defines how an agent invokes a tool, A2A defines how two agents delegate a task. It provides agent maps (opportunity advertisements), task lifecycle states, and three modes of interaction: 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 messaging without the full coordination semantics of A2A. This is useful in systems where simple message passing is sufficient and the lifecycle overhead of A2A tasks is unnecessary.
ANP is a detection and identification protocol. It uses Decentralized Identifiers (DIDs) to identify an agent and JSON-LD graphs to describe capabilities, providing a framework for decentralized agent markets where no central registry is required.
The emerging stack is: opportunity discovery via ANP or simpler registries, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP for cases that don’t require full task lifecycle management. These layers are complementary, not competing.
The transport problem remained
Every protocol on this list works over HTTP. This shows where the protocols came from: research groups, API providers, and enterprise software companies are building systems where HTTP is the undisputed view. HTTP is a protocol that they know is already talking on their servers and that makes demos easy.
The production problem is that HTTP assumes the server is available. Behind Network Address Translation (NAT) – and 88% of network devices are behind NAT – there is no server available without a relay. For groups of agents that need to route tasks directly between peers across cloud boundaries, home networks, and edge deployments, this centralization forces every message to pass through a relay infrastructure. Relay infrastructure adds latency, cost, and failure mode.
Application layer protocols decide the semantics of what agents say to each other. They do not decide how agents find each other and establish direct connections. 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.
Technologies for its solution exist. 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 tunnel-level encryption without a CA. Quick UDP Internet Connections (QUIC) (RFC 9000) or User Datagram Protocol (UDP) sliding-window user protocols provide reliable delivery without TCP head-of-line blocking. These are the same primitives that WireGuard uses for VPN tunnels and WebRTC for browser-to-browser media streams.
What is different in the agent context is capability-based routing. Agents should find partners not by hostname, but by what they can do. The research agent must be able to query "which counterparts have real-time foreign exchange data?" and get a list of active specialized agents. It is closer to a service registry than DNS and is a natural extension of the ANP design philosophy applied to the transport layer.
Several projects collect these pieces. The Pilot Protocol has the most comprehensive published specification with the IETF Internet Project covering addressing, tunneling, and NAT traversal for agent networks. libp2p provides a battle-tested framework with similar primitives. The IETF’s QUIC Working Group is developing extensions to NAT traversal that would be relevant here.
What will convergence look like?
HTTP-based protocols (MCP, A2A) are already approaching stable versions. The next 12 months will see production improvements, security improvements, stateless MCP servers for horizontal scaling, better A2A federation — instead of new fundamental designs. The tool call and task coordination layers are mostly resolved.
The transport layer lags by 18 to 24 months. Expect a period of implementation diversity as teams experiment with different approaches to peer-to-peer (P2P) agent networks, followed by consolidation around a small number of implementations as empirical data on performance and reliability accumulates. The IETF and W3C standardization directions are likely to produce something in the 2027-2028 window, by which time one or two open source implementations have accumulated enough production deployments to establish de facto standards ahead of an official specification.
For engineering leaders making architectural decisions today, multi-layered adoption is of practical importance. Application layer protocols are stable enough to create. Taking MCP is now low risk. Adopting A2A for multi-agent coordination is reasonable given the expectation that the protocol will evolve. The transport layer is where you either build something to order and plan to replace it, or you evaluate early implementations knowing that the space is still moving.
The teams that will have the most impact when the transport layer stabilizes are those that have designed their agent systems with a clear separation between application semantics (MCP, A2A) and transport (everything below). Clean separation is cheap to implement now and expensive to upgrade later, a lesson the microservices era taught anyone trying to add observability or chain breaking to systems that didn’t have them.
Philip Stoecki is the co-founder of Vulture Labs.