Agent Transport Layer: The Missing Piece After MCP and A2A

MCP solved tool calling. A2A solved coordination. But something in between — the actual transport mechanism for moving agent messages across network boundaries — remains an unsolved, contested space in 2026. If you’re building production agent systems today, this gap is not academic. It will bite you.

The Protocol Stack That Emerged

The agent protocol ecosystem has clarified considerably over the past 18 months. By mid-2026, the field converged on a rough three-layer model:

Layer 1 — Tool Interface (MCP): The Model Context Protocol handles how an agent discovers available functions, invokes them, and parses responses. Think of it as the USB of AI — a standardized plug for attaching capabilities. MCP servers now number in the hundreds, covering file systems, databases, web browsers, and every SaaS API imaginable. The spec is stable, the SDKs are mature, and adoption is broad.

Layer 2 — Agent Coordination (A2A): Google’s Agent-to-Agent protocol addresses a different problem: how two agents — potentially from different vendors, running in different environments — negotiate a shared task, exchange context, and collaborate on multi-step work. A2A introduces the Agent Card concept for capability discovery and a task negotiation protocol for establishing shared goals. By April 2026, over 150 organizations had adopted it, with Microsoft publishing formal Learn documentation.

Layer 3 — Transport: And here the stack falls apart. Neither MCP nor A2A specifies how messages actually travel. They define message formats and negotiation semantics but remain agnostic to HTTP, WebSockets, Server-Sent Events, gRPC streams, or message queues. In practice, this means every implementation makes independent, incompatible choices.

Why Transport Isn’t Just an Implementation Detail

The transport layer is where architecture decisions get expensive. HTTP/1.1 long-polling works for demos but breaks under production load. WebSockets introduce connection state that a stateless service model has to consciously manage. Server-Sent Events are unidirectional — fine for notifications, useless for bidirectional agent对话. gRPC streams offer bi-directional multiplexing but require HTTP/2 infrastructure and generate binary payloads that complicate debugging.

The VentureBeat analysis from June 2026 put it precisely: MCP solved the interface problem (what can I call?), A2A solved the coordination problem (who does what?), but the transport problem (how do bytes actually move?) remains fragmented.

This matters practically. Consider an agent pipeline where a orchestration agent needs to delegate work to a specialized coding agent running in a separate cloud environment. MCP tells the orchestrator what tools the coding agent exposes. A2A tells both how to negotiate the task. But getting the actual function call payload across the network boundary — with proper authentication, retry logic, timeout handling, and streaming response support — requires implementation-specific glue that the protocols deliberately don’t specify.

The Firewall Problem No One Talks About

There’s a second-order issue that compounds the transport gap: enterprise firewalls were not designed for AI agent traffic patterns.

Traditional enterprise traffic follows predictable patterns — client-server HTTPS to known domains, well-formed HTTP headers, finite request-response cycles. Agent traffic looks different: long-lived streaming connections, bidirectional message bursts, connections to dynamically discovered endpoints, and traffic that may hop between multiple agent services in a single user request.

Zscaler’s analysis of AI traffic through enterprise security stacks found that MCP and A2A traffic patterns frequently trigger legacy security systems. WebSocket connections get flagged as suspicious. Long-running streaming requests time out on idle timeout rules. Dynamic endpoint discovery runs afoul of allowlist-only egress policies.

The result: production agent deployments increasingly need dedicated network infrastructure — outbound-only mTLS tunnels, explicit proxy configurations, and custom routing layers — not because the protocols are broken, but because the transport assumptions don’t match enterprise network topologies.

What Actually Works in Production Today

Having watched teams deploy agent systems through 2025 and into 2026, the transport patterns that survive contact with production look like this:

For single-datacenter, single-tenant deployments: plain HTTP/2 with JSON payloads dominates. Simple to debug, simple to proxy, simple to secure with standard mTLS. The overhead is acceptable when all agents run in the same network segment.

For multi-tenant or cross-cloud setups: the pattern shifts to dedicated message buses — Redis Streams, Amazon SQS, or Apache Kafka — as the transport backbone. Agents communicate by publishing and subscribing to named channels rather than maintaining direct connections. This adds latency but decouples producers from consumers and provides natural backpressure when downstream agents are overwhelmed.

For browser-based agents: Server-Sent Events remain the pragmatic choice despite their unidirectional limitation. The alternative — WebSocket with a custom bidirectional framing layer — introduces complexity that most browser-agent projects can’t justify.

What doesn’t work: treating transport as an afterthought and assuming “we’ll use HTTP like everything else.” At scale, the difference between HTTP/1.1 and HTTP/2, between blocking I/O and async streams, between connection-per-request and connection pooling, translates directly to dollars and latency numbers.

The Unresolved Question

The protocol stack will continue maturing. MCP’s July 2026 stateless specification update addressed session state management at the protocol level, removing the last major ambiguity in the tool-calling interface. A2A’s adoption curve suggests the coordination layer will stabilize within the next several months.

But the transport layer sits in a different kind of uncertainty. It’s not a specification problem — it’s an infrastructure problem that every team has to solve for their specific deployment context. There is no equivalent of what MCP did for tool calling, because the solution is inherently environment-dependent.

The teams that get this right treat transport as a first-class architectural decision, not an implementation footnote. They profile their actual traffic patterns before choosing WebSockets over SSE. They instrument connection-level metrics before deploying across firewall boundaries. They treat the transport layer as the load-bearing infrastructure it actually is, not as commodity plumbing.

If you’re building agent systems today, this is where the unsolved problems live. MCP and A2A gave the ecosystem a shared vocabulary. The transport layer is where shared infrastructure still needs to be built.