Twelve months ago, most agent teams cared about one protocol: MCP. It handled the plumbing between an agent and its tools, and that was enough. Then A2A showed up to handle agent-to-agent coordination. And now AG-UI is standardizing how agents talk to the humans staring at the screen. Three protocols, three layers, and a whole new category of bugs living in the seams between them.
The Stack as of April 2026
MCP sits at the bottom. JSON-RPC calls from an agent to a tool server — read a database, invoke an API, fetch a file. Vertical. One agent, many capabilities.
A2A occupies the middle. Agent Cards for discovery, task objects for lifecycle management, streaming for long-running work. Horizontal. Multiple agents negotiating who does what. Version 1.0 landed five days ago with signed cards, gRPC support, and native multi-tenancy.
AG-UI lives at the top. Born from CopilotKit's work with LangGraph and CrewAI, it's an event-based protocol that standardizes how an agent's internal state, reasoning, and outputs reach a user interface. Streaming tokens, tool execution notifications, shared state with conflict resolution, human-in-the-loop interrupts — about 16 event types in total. Amazon Bedrock AgentCore adopted it in March.
Each layer solves a genuine problem. The interesting part is what happens at the boundaries.
The MCP-to-A2A Seam
MCP thinks in tool calls. Agent sends a request, tool server returns a result. The agent stays in charge, always.
A2A thinks in tasks. One agent creates a task, another picks it up, works on it — possibly for hours — and streams back status updates. Neither agent has full control. They negotiate through capability descriptions published in Agent Cards.
The friction shows up when an agent discovered via A2A needs to invoke tools through MCP internally. The A2A task carries its own lifecycle (submitted → working → completed). The MCP tool calls buried inside it carry theirs. When a tool call fails midway through a delegated task, the protocols disagree on who's responsible. Does the A2A task transition to a failed state? Does the receiving agent silently retry the tool call? The answer depends entirely on your application code, because neither protocol spec addresses cross-boundary error propagation.
Before v1.0, most teams sidestepped this by keeping MCP internal to each agent and using A2A only for coarse handoffs — "here's the research task, come back when you're done." The new gRPC transport and multi-tenancy support make tighter coupling possible, but reference architectures for how these layers should interact don't exist yet. You'll write your own, debug your own, and curse your own.
The A2A-to-AG-UI Seam
A2A streams task-level events: taskStatusUpdate when something changes, taskArtifactUpdate when output is ready. Coarse-grained, intentionally.
AG-UI streams fine-grained interaction events — text deltas token by token, tool execution start and end markers, thinking traces, state snapshots, interrupt requests. The semantic gap between these two models is wider than the naming suggests. A2A's "working" status doesn't decompose into AG-UI's granular stream because they operate at fundamentally different levels of abstraction.
The practical consequence: when your orchestrator agent delegates a sub-task via A2A and your frontend shows progress via AG-UI, someone must write a translation layer between task-level updates and token-level events. That someone is you. The protocol specs acknowledge each other's existence but don't define how they compose.
This is solvable engineering — you map A2A status transitions to AG-UI lifecycle events, you forward artifacts as AG-UI state updates — but it's bespoke work per application. No framework handles it automatically today.
Identity Is the Real Problem
This one wakes you up at 2 AM.
MCP runs OAuth 2.1 with dynamic client registration and per-server token scoping. A2A v1.0 introduced signed Agent Cards using JWS and JSON Canonicalization for cryptographic identity verification, plus its own OAuth 2.0 flows with PKCE and a new Device Code grant for CLI tools. AG-UI piggybacks on whatever transport auth you're already running — bearer tokens over HTTP, session cookies over WebSocket.
Three protocols, three identity models. When agent A discovers agent B through an A2A Agent Card, then agent B calls a tool via MCP, then results propagate back through AG-UI to a user's browser — you've crossed three authentication boundaries. The user's identity may or may not have survived the journey.
Last week's post on MCP token passthrough covered one edge of this problem. Multiply it by two more protocol boundaries and you see the full shape of the challenge.
What Teams Actually Deploy
Here's the part nobody says on stage: most production systems in April 2026 use one of these protocols. Occasionally two. The full three-layer stack exists in architecture diagrams and conference keynotes, not in systems handling real traffic at scale.
Shipping teams tend to land on one of three patterns:
MCP-only. Single agent, multiple tools. No multi-agent coordination, no specialized UI protocol. The agent calls tools, formats results, returns them. This covers roughly 80% of deployed use cases and is boring in exactly the right way.
MCP + A2A. An orchestrator delegates to specialized agents via A2A, each calling their own tools via MCP. UI is a custom integration — often just a chat interface polling for final results. Tyson Foods and Gordon Food Service run this pattern in supply chain coordination.
MCP + AG-UI. Single agent with a rich, reactive frontend. The agent calls tools via MCP and streams its internal state to the UI through AG-UI events. CopilotKit-based applications live here. No agent-to-agent coordination needed.
The full MCP + A2A + AG-UI stack? AWS's AgentCore supporting AG-UI and Microsoft's Agent Framework supporting both A2A and MCP suggest the hyperscalers are converging toward it. The integration middleware will probably exist by Q3. Probably.
So What Do You Do?
Don't architect for three protocols on day one. Pick the layer where your actual problem lives.
Coding assistant that needs GitHub, a database, and documentation access? MCP. Ship it.
Workflow where a research agent hands off to a writer who hands off to a reviewer? A2A on top of MCP. Add AG-UI later if users genuinely need to observe the handoffs in real time — most don't.
In-app copilot where users watch agent reasoning, interrupt mid-task, and steer corrections? AG-UI over MCP. Bring in A2A only when you need genuinely autonomous sub-agents, not just parallel tool calls dressed up as agents.
The layering makes architectural sense. The protocols are individually well-designed. But the seams between them are uncharted territory, and the teams that adopt all three before the integration tooling matures will spend more time on protocol plumbing than on their product. Add layers when the pain demands it, not when the diagram looks elegant.