AI Agents: Tool Calling & Coordination Solved, Transport Still

The rapidly evolving landscape of AI agent communication is witnessing a familiar pattern: initial proliferation of protocols, followed by gradual consolidation. While significant progress has been made in standardizing how AI agents call tools and coordinate tasks, a critical challenge remains at the transport layer, impacting the scalability and direct connectivity of distributed agent fleets.

This trend echoes the history of distributed computing, where protocols like CORBA and DCOM eventually gave way to simpler, HTTP-native solutions like REST, and diverse messaging standards converged into MQTT and WebSockets. Each new computing paradigm sparks a flurry of competing standards before interoperability becomes an economic necessity, driving convergence.

The AI agent ecosystem is currently navigating this phase, with four prominent protocols emerging in the past year and a half. These include Anthropic's Model Context Protocol (MCP) from late 2024, IBM Research's Agent Communication Protocol (ACP) in March 2025, Google's Agent2Agent (A2A) in April 2025, and the independent Agent Network Protocol (ANP). Industry bodies like the W3C and IETF are actively engaged in standardization efforts, underscoring the urgency of these developments.

Dissecting the Agent Protocol Stack

The apparent chaos of protocol proliferation masks a more organized reality, as most new standards address distinct layers of the communication stack rather than directly competing. The key is understanding each protocol's specific role:

• Model Context Protocol (MCP): Developed by Anthropic, MCP has become the de facto standard for tool calling. It defines how an AI model discovers, invokes, and interprets responses from server-exposed functions. Functioning as a typed remote procedure call (RPC) over HTTP, MCP saw over 10,000 active public servers and 164 million monthly Python SDK downloads by April 2026, solidifying its dominance in this layer.

• Agent2Agent (A2A): Google's contribution, now donated to the Linux Foundation, addresses task coordination between agents. While MCP handles how an agent interacts with a tool, A2A governs how two agents delegate and manage tasks, introducing concepts like Agent Cards (capability advertisements), task lifecycle states, and various interaction modes (synchronous, streaming, asynchronous). It fills a crucial gap left by MCP.

• Agent Communication Protocol (ACP): From IBM Research, ACP offers a lightweight, stateless message envelope for simple agent-to-agent exchanges. It's designed for scenarios where full task lifecycle management, as provided by A2A, is unnecessary.

• Agent Network Protocol (ANP): An independent initiative, ANP focuses on discovery and identity. It leverages Decentralized Identifiers (DIDs) for agent identity and JSON-LD graphs for capability descriptions, laying the groundwork for decentralized agent marketplaces without central registries.

This synergy suggests an emerging stack: capability discovery through ANP or similar registries, task coordination via A2A, tool calls using MCP, and ACP for basic messaging. These protocols are largely complementary, not competitive.

The Lingering Transport Challenge

Despite advancements in application-layer semantics, a significant hurdle remains at the session layer: transport. All current protocols—MCP, A2A, ACP, and ANP—rely on HTTP. This dependency creates a critical limitation because HTTP presumes a directly reachable server, a condition often unmet by the 88% of networked devices behind Network Address Translation (NAT).

For distributed agent fleets needing direct peer-to-peer routing across diverse network boundaries (cloud, home, edge), HTTP's requirement for a reachable server necessitates relay infrastructure. This relaying introduces undesirable latency, cost overhead, and additional points of failure, directly impacting performance and resilience.

The core issue is that these application-layer protocols define what agents say, but not how they find each other and establish direct connections. This problem falls under the session layer (OSI Layer 5) and is not addressed by the current standards.

The necessary technical primitives to overcome this exist, drawn from established networking solutions. These include UDP hole-punching with STUN for NAT traversal (effective for about 70% of network topologies), secure tunnel-level authentication and encryption using X25519 Diffie-Hellman and AES-256-GCM, and reliable data delivery over UDP via QUIC or custom sliding-window protocols to avoid TCP's head-of-line blocking. These are the same foundational technologies powering VPNs like WireGuard and browser-to-browser media streams in WebRTC.

However, the agent context introduces a unique requirement: capability-based routing. Agents need to discover peers not by traditional network addresses but by their capabilities—for instance, an agent querying, "which peers have real-time foreign exchange data?" This necessitates a service registry-like approach at the transport layer, an extension of ANP's decentralized discovery philosophy.

Several promising projects are synthesizing these components. Pilot Protocol offers a comprehensive IETF Internet-Draft on agent addressing, tunnel establishment, and NAT traversal. libp2p provides a robust foundation with similar primitives, and the IETF's QUIC working group is developing relevant NAT traversal extensions.

Navigating Future Convergence

The trajectory of AI agent protocols points to a bifurcated timeline. The HTTP-based application-layer protocols, MCP and A2A, are largely settling. The next 12 months will see them mature through production hardening, security enhancements, and improved federation, with fundamental designs remaining stable. Tool calling and task coordination are, for practical purposes, considered solved.

Conversely, the transport layer lags by 18 to 24 months. This period will be characterized by diverse implementations as teams experiment with different peer-to-peer (P2P) agent networking approaches. Consolidation will follow as empirical performance data emerges. Formal standards from the IETF and W3C are anticipated in the 2027-2028 timeframe, likely preceded by one or two open-source implementations establishing de facto standards through widespread production deployment.

For technology leaders making architectural decisions today, a layered adoption strategy is key. Building on the stable application-layer protocols like MCP is low-risk, and A2A adoption is reasonable, with an expectation of continued evolution. However, the transport layer is where organizations must either develop custom solutions with a clear upgrade path or cautiously evaluate early implementations, recognizing the fluidity of the space.

Teams that prioritize a clean separation between application semantics (e.g., MCP, A2A) and the underlying transport layer will gain significant leverage as transport solutions stabilize. This architectural foresight, a lesson learned from the microservices era regarding observability and circuit breaking, is inexpensive to implement now but costly to retrofit later.

FAQ

Q: What is the primary communication problem that AI agent protocols are still trying to solve?

A: The main challenge lies in the transport layer, specifically enabling direct peer-to-peer connections for agents behind network address translation (NAT) without relying on costly and latency-inducing relay servers. This involves establishing direct connections and capability-based routing.

Q: How do MCP and A2A protocols differ in their functions?

A: MCP (Model Context Protocol) is designed for tool calling, defining how an AI model interacts with and uses external functions. A2A (Agent2Agent) focuses on task coordination, outlining how two or more agents delegate, manage, and complete shared tasks.

Q: When are standardized transport solutions for AI agents expected to emerge?

A: While current application-layer protocols are largely stable, the transport layer is anticipated to see significant experimentation and consolidation over the next 18 to 24 months. Formal standards from bodies like the IETF and W3C are likely to appear in the 2027-2028 timeframe, potentially following the establishment of de facto open-source standards.