The history of distributed computing is a story of protocol proliferation followed by hard-won consolidation, and the AI agent ecosystem is writing its own chapter right now. Over the past eighteen months, four major protocols have been published—Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent2Agent (A2A), and Agent Network Protocol (ANP)—each vying to define how autonomous agents discover, coordinate, and communicate. Yet while these standards are rapidly solving the semantic layers of tool calling and task coordination, a fundamental transport problem remains unresolved: how agents behind firewalls and network address translation (NAT) find and connect directly to one another. Understanding which layers are stable and which are still in flux has real consequences for engineering leaders making architecture decisions today.
What the AI agent protocols actually solve
The apparent chaos in the agent protocol landscape is more structured than it looks. Most of these standards address different layers of a networking stack rather than competing for the same slot. The confusion comes from marketing language that 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 the functions a server exposes, how to invoke those functions, 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. By April 2026, the Linux Foundation confirmed more than 10,000 active public MCP servers and 164 million monthly Python SDK downloads. MCP has effectively won the tool-calling layer; the standardization work is 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), a task lifecycle state machine, and three interaction modes: synchronous, streaming, and asynchronous. Google donated A2A to the Linux Foundation in June 2025, and enterprise AI teams have adopted it widely because it fills a gap that MCP leaves open.
ACP is a message envelope format. It is lightweight and stateless, designed for simple agent-to-agent message exchange without the full coordination semantics of A2A. ACP is useful in systems where straightforward 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 emerging stack is complementary: 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 lifecycle management.
The AI agent transport problem that remains
Every protocol in this list runs over HTTP. This reflects their origins: 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 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. Relays add latency, cost, and a new 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 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. QUIC (RFC 9000) or custom sliding-window protocols over 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 and A2A—are already converging on stable versions. The next twelve months will see production hardening, security improvements, stateless MCP servers for horizontal scaling, and better A2A federation—rather than new fundamental designs. The tool-calling and task-coordination layers are largely solved.
The transport layer is eighteen to twenty-four months behind. Expect a period of implementation diversity as teams experiment with different approaches to peer-to-peer 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 any formal specification.
What this means for engineering leaders
For teams 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 and 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.
A direct answer to the key question: What is the single most critical unsolved problem in AI agent protocols today?
The most critical unsolved problem is transport-layer connectivity for agents behind NAT. All major agent protocols run over HTTP, which assumes a reachable server. Roughly 88% of networked devices sit behind NAT, making direct peer-to-peer connections impossible without relay infrastructure. Solving this requires session-layer technologies—UDP hole-punching, STUN, and authenticated encryption—combined with capability-based routing so agents can find peers by function rather than by hostname. This transport problem is 18 to 24 months behind the application-layer protocols in maturity.
For now, the smartest investment is in architectural separation. Build your agent systems with application semantics cleanly decoupled from transport. That one design choice will determine how easily you can adopt whatever transport standard emerges once the industry converges.
