MCP solved tool calling. A2A solved coordination. What solves transport?
Our take
The current state of AI agent communication mirrors a familiar pattern in distributed computing: a burst of innovation followed by inevitable consolidation. We’ve seen this play out before, most notably with the enterprise integration protocols of the late 90s, where a crowded field of contenders like CORBA, DCOM, and RMI ultimately yielded to the simplicity and ubiquity of REST As AI companies race to go public, who else is along for the ride?. Similarly, the fragmentation of real-time messaging eventually resolved around MQTT and WebSockets. Now, the AI agent ecosystem is undergoing a similar proliferation, with protocols like MCP, A2A, ACP, and ANP vying for dominance. Understanding this cyclical nature is crucial, as it suggests that the current flurry of activity isn't a chaotic free-for-all, but a necessary step towards establishing a more streamlined and interoperable future for AI agents, a point underscored by the recent analysis of the OpenAI IPO The Real Reason for the OpenAI IPO: It’s Not About the Models.
What’s particularly insightful about Stayetski’s analysis is the delineation of these protocols’ distinct roles. It’s not a case of direct competition, but rather a layered architecture emerging. MCP handles tool calling, A2A coordinates tasks between agents, ACP facilitates lightweight messaging, and ANP addresses discovery and identity. This breakdown clarifies the confusion often surrounding these protocols, which are frequently marketed as universal solutions. The identification of the “transport problem” – the lack of a robust, peer-to-peer communication layer – is especially pertinent. The reliance on HTTP, while pragmatic for initial development and demos, introduces a centralization bottleneck via NAT, hindering the scalability and efficiency of agent fleets operating across diverse network environments. The potential solutions—UDP hole-punching, QUIC, and the like—are well-established technologies, the challenge lies in integrating them with the emerging agent protocols and defining capability-based routing, a critical step towards truly decentralized agent networks.
The projection of convergence within the next 12-24 months is a reasonable assessment. The application-layer protocols (MCP, A2A) are already solidifying, with ongoing improvements focused on production hardening and federation. The real action, however, will be in the development and stabilization of the transport layer, where experimentation with P2P networking approaches will likely lead to the emergence of dominant implementations. This mirrors the evolution of WebRTC and WireGuard, technologies that similarly solved peer-to-peer connectivity challenges. The emphasis on clean separation between application semantics and transport is a crucial takeaway for engineering leaders—a principle that, as Stayetski points out, was learned the hard way during the microservices boom. Architecting for modularity and adaptability now will pay dividends as the agent communication landscape matures.
Ultimately, the future of AI agent communication hinges on solving the transport layer challenge. The teams that can decouple application logic from transport mechanisms will be best positioned to capitalize on the eventual convergence. While the rapid pace of innovation can feel overwhelming, remembering the historical patterns of distributed computing offers a valuable perspective. The current proliferation is a necessary stage in the journey towards a more efficient, interoperable, and decentralized AI agent ecosystem. The question now is: which implementation of P2P agent networking—or perhaps a novel approach altogether—will ultimately become the de facto standard, and what new architectural considerations will arise as agents increasingly operate autonomously across complex and heterogeneous networks?
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 carved out their respective niches. Every new computing paradigm generates a burst of competing standards, then slowly converges as implementations accumulate and interoperability becomes economically necessary.
The AI agent ecosystem is currently in the proliferation phase. Four significant protocols have been published in the past eighteen months: Model context 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. Conferences are running workshops on interoperability. Every week brings a new GitHub repository claiming to solve the agent communication problem.
Understanding where and how quickly this converges has real consequences for architecture decisions being made right now.
What the protocols actually solve
The proliferation looks 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 which aspect of communication.
MCP is a tool-calling interface. It defines how a model discovers what functions a server exposes, how to invoke 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 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. The standardization work is effectively done.
A2A is a task coordination interface. Where MCP defines how an agent calls a tool, A2A defines how two agents delegate a task. It introduces Agent Cards (capability advertisements), task lifecycle states, and three interaction modes: Synchronous, streaming, and asynchronous. Google donated it to the Linux Foundation in June 2025, and enterprise AI teams have adopted it broadly 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 A2A's full coordination semantics. It is useful in systems where simple message passing suffices and A2A's task lifecycle overhead is unnecessary.
ANP is a discovery and identity protocol. It uses Decentralized Identifiers (DIDs) for agent identity and JSON-LD graphs for capability descriptions, providing a foundation for decentralized agent marketplaces where no central registry is 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 rather than compete.
The transport problem that remains
Every protocol in this list runs over HTTP. This reflects where the protocols came 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 speak, and the one that makes demos easy.
The production problem is that HTTP assumes a reachable server. Behind network address translation (NAT) — and 88% of networked devices sit behind NAT — there is no reachable server 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 every message through relay infrastructure. Relay infrastructure adds latency, cost, and a failure mode.
The application-layer protocols solve the semantics of what agents say to each other. They do not solve how agents find each other and establish direct connections. That is a session-layer problem, Layer 5 in the open systems interconnection (OSI) model and none of MCP, A2A, ACP, or ANP address it.
The technologies for solving it exist. UDP hole-punching with session traversal utilities for NAT (STUN) provides NAT traversal for roughly 70% of network topologies. X25519 Diffie-Hellman and AES-256-GCM provide authenticated encryption at the tunnel level without a certificate authority. Quick UDP internet connections (QUIC) (RFC 9000) or custom sliding-window protocols over 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 that WebRTC uses for browser-to-browser media streams.
What differs in the agent context is capability-based routing. Agents need to find peers not by hostname but by what those peers can do. A research agent should be able to query "which peers have real-time foreign exchange data?" and receive a list of currently active specialist agents. This is closer to a service registry than to DNS, and it is a natural extension of ANP's design philosophy applied to the transport layer.
A handful of projects are assembling these pieces. Pilot Protocol has the most complete published specification, with an IETF Internet-Draft covering addressing, tunnel establishment, and NAT traversal for agent networks. libp2p provides a battle-tested foundation with similar primitives. The IETF's QUIC working group is developing NAT traversal extensions that will be relevant here.
What convergence will look like
The HTTP-based protocols (MCP, A2A) are already converging on stable versions. The next 12 months will see production hardening, security improvements, stateless MCP servers for horizontal scaling, better A2A federation — rather than new fundamental designs. The tool-calling and task-coordination layers are largely solved.
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 once empirical data on performance and reliability accumulates. 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 ahead of the formal specification.
For engineering leaders making architecture decisions today, the practical implication is layered adoption. The application-layer protocols are stable enough to build on. MCP adoption now is low-risk. A2A adoption for multi-agent coordination is reasonable with the expectation that the protocol will evolve. The transport layer is where you either build something custom and plan to replace it, or you evaluate early implementations knowing the space is still moving.
The teams that will have the most leverage when the transport layer stabilizes are the ones that designed their agent systems with a clean separation between application semantics (MCP, A2A) and transport (whatever sits below). Clean separation is cheap to implement now and expensive to retrofit later, a lesson the microservices era taught anyone who tried to add observability or circuit breaking to systems that had none.
Philip Stayetski is a co-founder of Vulture Labs.
Read on the original site
Open the publisher's page for the full experience