The history of distributed computing consists of protocol diffusion followed by consolidation.
Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Java remote method invocation (RMI), and the original simple object access protocol (SOAP) competed for the enterprise integration market in the late 1990s, with representational state transfer (REST) quietly winning, being simpler and HTTP-native.
Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), and many specialized protocols fragmented real-time messaging before MG telemetry transport (MQTT) and WebSockets created their respective sockets. Each new computing paradigm creates an explosion of competing standards that then slowly converge as applications accumulate and interoperability becomes economically necessary.
The AI agent ecosystem is currently in a proliferating phase. Four important protocols have been published in the last 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 standard path. The Internet Engineering Task Force (IETF) adopts Internet-Drafts on agent transport. Seminars on interaction are held at the conferences. Every week, the agent brings a new GitHub repository that claims to solve the communication problem.
Understanding where and how quickly this converges has real implications for architectural decisions being made today.
What do protocols actually solve?
The spread looks more chaotic than it is because most of these protocols address different layers of the stack instead of competing for the same slot. The confusion comes from marketing describing each "A standard for AI agent communication" without specifying which aspect of the communication.
MCP is a tool calling interface. It defines what functions the server exposes to the model, how to invoke them, and how to interpret the response. This is a remote procedure call (RPC) contract written between a model client and a tool server that runs over HTTP. The Linux Foundation has confirmed over 10,000 active public MCP servers and 164 million monthly Python SDK downloads by April 2026. MCP has already gained the instrument summoning layer. Standardization works are carried out effectively.
A2A is a task coordination interface. While MCP defines how an agent invokes a tool, A2A defines how two agents delegate a task. It provides 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 it has been widely adopted by enterprise AI teams because it fills a real gap left open by MCP.
ACP is a message envelope format. Designed for lightweight, stateless, agent-to-agent message exchange without the full coordination semantics of A2A. Useful in systems where simple message passing is sufficient and the task lifetime overhead of A2A is unnecessary.
ANP is a discovery and identity protocol. It uses Decentralized Identifiers (DID) for agent identity and JSON-LD graphs for capability descriptions, laying the groundwork for decentralized agent marketplaces where no central registry is required.
The resulting stack: capability discovery via ANP or simpler registers, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP for situations that do not require full task lifecycle management. These layers complement rather than compete.
The remaining transport problem
Every protocol on this list works over HTTP. This reflects where the protocols came from: Research groups, API providers, and enterprise software companies building systems where HTTP was an unquestioned assumption. HTTP is the protocol they know, their servers already speak, and it’s the protocol that makes demos easy.
The production problem is that HTTP accepts an accessible server. Behind network address translation (NAT) – and 88% of networked devices sit behind NAT – there is no server reachable without a relay. For fleets of agents that must route tasks directly between peers across cloud boundaries, home networks, and edge deployments, this centralization forces every message through a relay infrastructure. Relay infrastructure adds latency, cost, and failure mode.
Application layer protocols resolve the semantics of what agents say to each other. They do not address how agents find each other and establish direct relationships. This is a session layer problem, Layer 5 in the open systems interconnection (OSI) model, and none of MCP, A2A, ACP, or ANP address this problem.
There are technologies for its solution. UDP tunnels with session switching utilities for NAT (STUN) provide NAT traversal for about 70% of network topologies. X25519 Diffie-Hellman and AES-256-GCM provide tunnel-level authenticated encryption without a certificate authority. Special sliding window protocols over Quick UDP Internet Connections (QUIC) (RFC 9000) or User Datagram Protocol (UDP) ensure reliable delivery without linear blocking of TCP. These are the same primitives that WireGuard uses for VPN tunnels and that WebRTC uses for browser-to-browser media streams.
What differentiates the agent context is capability-based routing. Agents should find their peers by what their peers can do, not by their first name. A research agent must be able to conduct a survey "Which peers have real-time currency data?" and get a list of currently active specialist agents. It is closer to a service registry than DNS, and is a natural extension of ANP’s design philosophy applied to the transport layer.
Several projects combine these pieces. The Pilot Protocol has the most complete published specification by the IETF Internet Project, covering addressing, tunneling, 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 will convergence look like?
HTTP-based protocols (MCP, A2A) are now integrated in stable versions. The next 12 months will see production hardening, security improvements, stateless MCP servers for horizontal scaling, better A2A federation from new fundamental designs. The tool-call and task-coordination levels are largely resolved.
The transport layer lags by 18 to 24 months. Expect a period of application diversity as teams test different approaches to peer-to-peer (P2P) agent networking, followed by consolidation around a small number of applications as empirical data on performance and reliability are gathered. The IETF and W3C standardization tracks will likely produce something in the 2027-2028 window, by which time one or two open source applications will have accumulated enough production deployments to create de facto standards before official specifications.
The practical implication for engineering leaders making architectural decisions today is layered adoption. Application layer protocols are stable enough to build. Taking MCP 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 either build something special and plan to replace it, or you evaluate early implementations knowing that the ground is still moving.
The teams that will gain the most leverage when the transport layer is stabilized are those that design their agent systems with a clean separation between application semantics (MCP, A2A) and transport (whatever is underneath). Clean isolation is cheap to implement now and expensive to retrofit later, a lesson the microservices era has taught anyone trying to add observables or loop interrupts to any system.
Philip Stayetski is the co-founder of Vulture Labs.
