MCP and A2A settled their layers. The transport layer is the gap.
The application layer of agent protocols is settling into a stack, and the unresolved problem has moved to transport. Four protocols have defined agent communication over the past eighteen months: Model Context Protocol from Anthropic in late 2024, Agent Communication Protocol from IBM Research in March 2025, Agent2Agent from Google in April 2025, and Agent Network Protocol from an independent working group. The popular framing treats these as competitors for "the agent communication standard." According to the article, that framing comes from marketing, not architecture: each protocol addresses a different layer of the stack, and the competition dissolves once the layers are named.
MCP defines a typed remote procedure call contract between a model client and a tool server, running over HTTP. The Linux Foundation reports more than 10,000 active public MCP servers and 164 million monthly Python SDK downloads by April 2026. The tool-calling layer is effectively standardized, and the remaining work is production hardening rather than design.
A2A defines how two agents delegate a task, introducing Agent Cards, task lifecycle states, and three interaction modes: synchronous, streaming, and asynchronous. Google donated A2A to the Linux Foundation in June 2025, and enterprise teams have adopted it for the coordination gap that MCP leaves open. ACP, from IBM Research, is a lighter-weight message envelope format for cases where A2A's task lifecycle overhead is excessive. ANP handles discovery and identity using Decentralized Identifiers and JSON-LD graphs, supporting decentralized agent marketplaces where no central registry is required. Each protocol's design choice reflects the layer it serves, and none of them needs to subsume the others.
The stack is forming rather than competing. Capability discovery via ANP or simpler registries sits at one layer. Task coordination via A2A. Tool calls via MCP. Lightweight messaging via ACP where full task lifecycle management is excessive. The application layers complement each other, and the next twelve months will be hardening, not redesign.
The remaining problem sits at the transport layer. Every one of these protocols runs over HTTP. HTTP assumes a reachable server. According to the article, 88% of networked devices sit behind network address translation, where no reachable server exists without a relay. Agent fleets that route tasks directly between peers across cloud boundaries, home networks, and edge deployments face forced centralization: every message passes through relay infrastructure. Relay infrastructure adds latency, cost, and a single point of failure.
This is a session-layer problem, Layer 5 in the OSI model, and none of MCP, A2A, ACP, or ANP address it. The application-layer protocols solve what agents say to each other. They do not solve how agents find each other and establish direct connections.
The technologies for solving the transport problem exist and are well understood. According to the article, UDP hole-punching with 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, specified in 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. The work is assembly, not invention.
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 querying for "which peers have real-time foreign exchange data?" and receiving a list of currently active specialist agents is closer to a service registry than to DNS. This is a natural extension of ANP's design philosophy applied to the transport layer, and it has not yet been built.
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. The W3C AI Agent Protocol Community Group has opened a standards track, and the IETF is receiving Internet-Drafts on agent transport. The article's expectation is a period of implementation diversity before any single approach consolidates the field.
The article's timeline is plausible: the application-layer protocols are already converging, and the transport layer is 18 to 24 months behind. Expect implementation diversity through 2026, then consolidation as empirical data accumulates. Standards-track output from the IETF and W3C will likely land in 2027-2028, by which time one or two open-source implementations will have accrued enough production deployments to define de facto standards ahead of the formal specification.
Clean separation between application semantics and transport is the architectural choice that is cheap to implement now and expensive to retrofit later. MCP and A2A are stable enough to build on, and adopting them now carries low risk. The transport layer, however, is where any agent system needing peer-to-peer connectivity faces the choice described in the source: take on a custom layer that will need replacement later, or work with early implementations while the space is still moving.
The throughput under realistic P2P conditions is the measurement the source does not provide. Relay-based systems have known cost profiles. Direct peer connections have unknown cost profiles for agent workloads specifically, since capability-based routing at the transport layer has not been benchmarked at production scale. That gap is the architectural risk when an agent system is being designed to operate across network boundaries.