The history of distributed computing is one of protocol expansion 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 over the simplicity and availability of HTTP.
The Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), and a dozen proprietary protocols separated real-time messaging before MG telemetry transport (MQTT) and WebSockets drew their separate spaces. Every new computing paradigm produces competing standards, then gradually converge as implementations accumulate and interoperability becomes economically necessary.
The AI ecosystem is currently in an expansion phase. Four important protocols have been published in the last eighteen months: Content Model Protocol (MCP) from Anthropic in late 2024, Agent Communication Agent (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) receives Internet-Drafts from the transport agent. Conferences run workshops on collaboration. Every week brings a new GitHub repository that claims to solve the agent connection problem.
Understanding where and how these come together has real implications for architectural decisions being made today.
What is resolved by regulations
The expansion looks more chaotic than it is, because most of these agreements address different sections of the stack rather than competing for the same space. The confusion comes from advertising, which defines each as "level of interaction with the AI agent" without specifying which part of the connection.
MCP is a tool calling system. It describes how the model finds out what functions are exposed by the server, how to use them, and how to interpret the response. It is a typed remote procedure call (RPC) contract between the client and server model of the tool, which uses HTTP. The Linux Foundation has certified more than 10,000 active MCP servers and 164 million Python SDK downloads per month by April 2026. MCP has already won the tools calling layer. The configuration operation was performed successfully.
A2A is a functional interface. Where MCP describes how an agent calls a tool, A2A describes how two agents transfer work. It introduces Agent Cards (power ads), workflow states, and three modes of interaction: Synchronous, streaming, and asynchronous. Google donated it to the Linux Foundation in June 2025, and enterprise AI groups have widely embraced it 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 full A2A communication semantics. It is useful for applications where simple message passing is sufficient and A2A lifecycle work is unnecessary.
ANP is an authentication and identification protocol. It uses Decentralized Identifiers (DIDs) for agent identities and JSON-LD graphs for capability descriptions, providing the basis for decentralized agent marketplaces where no centralized registration is required.
Emerging stack: Power discovery via ANP or simple registration, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP in situations that do not require full task lifecycle management. These layers complement each other rather than compete.
The remaining transport problem
Every protocol on this list uses HTTP. This shows where the protocols are coming from: Research groups, API providers, and enterprise software companies that build systems where HTTP is an unquestionable assumption. HTTP is the protocol they know, the one their servers already talk about, and the one that makes demos easy.
The production problem is that HTTP takes a reachable server. After network address translation (NAT) — and 88% of networked devices sit behind NAT — no server is reachable without a relay. For enterprise fleets that need to route tasks directly between peers across cloud boundaries, home networks, and edge deployments, this integration forces all messages through a relay infrastructure. Transmission infrastructure adds latency, cost, and failure mode.
Application layer protocols resolve the semantics of what agents say to each other. They do not solve how agents find each other and establish direct communication. That’s a session layer problem, Layer 5 in the open systems connectivity (OSI) model and none of the MCP, A2A, ACP, or ANP addresses it.
The technology to solve it exists. UDP tunneling through session traversal NAT (STUN) services provides NAT traversal for about 70% of network headers. X25519 Diffie-Hellman and AES-256-GCM provide guaranteed encryption at the tunnel level without certificate authority. Quick UDP Internet Connection (QUIC) (RFC 9000) or customized window protocols over user datagram protocol (UDP) provide reliable delivery without TCP overhead. These are the same primitives that WireGuard uses for VPN tunnels and that WebRTC uses for browser-to-browser media streaming.
The exception to the agent context is the route based on capacity. Agents need to find peers not by host name but by what peers can do. A research agent should be able to ask questions "which peers have real-time foreign exchange data?" and find a list of currently active professional agents. This is closer to service registration than DNS, and is a natural extension of the ANP design philosophy used in the transport layer.
A number of projects include these pieces. The Pilot Protocol has the most complete specifications published, with an IETF Internet-Draft address, tunnel establishment, and NAT traversal in agent networks. libp2p provides a battle-tested base with similar primitives. The IETF QUIC working group is developing NAT traversal extensions that will work here.
What will the encounter look like?
HTTP-based protocols (MCP, A2A) are already evolving to stable versions. The next 12 months will see production stability, security improvements, stateless MCP servers for horizontal scaling, better A2A alliances – rather than new basic designs. The layers of tool calling and task integration are largely resolved.
The logistics layer is 18 to 24 months behind. Expect a period of mixed use as teams experiment with different approaches to the peer-to-peer (P2P) agent network, followed by integration with a relatively small number of uses once proof-of-concept data on performance and reliability have been gathered. 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 accumulated enough production submissions to establish de facto standards before official specification.
For engineering leaders making architectural decisions today, what works is layered discovery. Application layer protocols are stable enough to be built into them. MCP acquisition is now less risky. The adoption of A2A for multi-agent communication makes sense with the expectation that a protocol will emerge. The transport layer is where you build something custom and plan to change it, or test an early implementation knowing that the space is still moving.
The teams that will be most powerful when the transport layer is stable are those who design their agent systems with a clean separation between application semantics (MCP, A2A) and transport (whatever sits below). Pure isolation is cheap to implement now and expensive to reverse, a lesson the microservices era has taught anyone who’s tried to add visibility or circuit breakers to systems that don’t have them.
Philip Stayetski is the founder of Vulture Labs.
