MCP, A2A, and AG-UI are complementary protocols at three different layers of the agent stack — not competitors. MCP (Anthropic, 97M+ monthly SDK downloads) standardizes agent-to-tool communication. A2A (Google, 150+ organizations, v1.0 shipped) standardizes agent-to-agent delegation and discovery via Agent Cards. AG-UI (CopilotKit, 9K+ GitHub stars) standardizes agent-to-frontend streaming via ~17 typed event types. AWS Bedrock AgentCore supports all three as of March 2026. Most teams need MCP immediately, add A2A when they have multi-agent coordination, and add AG-UI when they need real-time agent UIs beyond simple chat.
Three weeks ago, a fintech client asked us to build a system where a compliance agent reviews transactions, a fraud detection agent flags anomalies, a remediation agent files SARs, and a dashboard shows the human compliance officer exactly what's happening in real time — including which agent made which decision and why.
We needed the compliance agent to query their KYC database and sanctions lists. We needed the three agents to delegate work to each other without exposing their internal reasoning chains. And we needed the officer's dashboard to stream every decision, tool call, and escalation as it happened — not after a batch job finished.
That's three different communication problems. And in 2026, there are three protocols designed to solve them: MCP for the tool calls, A2A for the agent delegation, and AG-UI for the real-time dashboard. Getting the layering right was the difference between a clean architecture and a tangled mess of custom WebSocket handlers.
The Three-Layer Problem
Most agent architectures involve three distinct communication boundaries, and conflating them is the most common mistake I see teams make.
Layer 1: Agent-to-Tool. Your agent needs to call a database, hit an API, read a file. This is a controlled, synchronous interaction where the agent invokes a capability and gets a result back. The agent is in charge.
Layer 2: Agent-to-Agent. Your agent needs to delegate a subtask to another agent — one that might use different models, different tools, and different reasoning strategies. The delegating agent doesn't control the delegate's internals. It sends a task and gets a result, possibly asynchronously.
Layer 3: Agent-to-User. Your agent needs to show a human what it's doing — streaming text, reporting tool call progress, requesting approval, synchronizing shared state. This is real-time, event-driven, and fundamentally different from request-response.
Each layer has different trust boundaries, different latency requirements, and different failure modes. Using one protocol for all three is like using HTTP for everything from database queries to real-time video — technically possible, architecturally painful.
MCP: The Agent-to-Tool Layer
If you're building AI agents in 2026, you already know MCP. Anthropic's Model Context Protocol crossed 97 million monthly SDK downloads in March 2026 and is now governed by the Linux Foundation's Agentic AI Foundation. Every major provider — Anthropic, OpenAI, Google, Microsoft, AWS — adopted it. We covered MCP in depth in our developer guide and our MCP vs API comparison, so I'll focus on where it fits in the protocol stack.
MCP solves a specific problem: how an agent discovers and invokes external tools, data sources, and services through a standardized interface. You wrap your existing systems in MCP servers that expose tools (actions), resources (read-only data), and prompts (reusable templates). The agent connects as a client, discovers what's available, and invokes capabilities at runtime — no hardcoded integrations, no client-side changes when you add a new tool.
What MCP Does Well
- Runtime discovery. Add a tool to your MCP server, and every connected agent can use it immediately. No redeployment.
- Typed schemas. Every tool has a JSON Schema definition for inputs and outputs. The agent knows exactly what to pass.
- Standardized auth. OAuth 2.1 with PKCE for remote connections. Your MCP server plugs into existing identity providers.
- Massive ecosystem. Over 13,000 public MCP servers on GitHub. If your agent needs to talk to Slack, Postgres, Stripe, or Jira, someone already built the server.
Where MCP Stops
MCP is agent-to-tool. The agent is the client. The tool is the server. The agent sees the tool's internals — its schema, its parameters, its response format. This works perfectly when one agent calls a database or an API. It breaks down when you need two autonomous agents to collaborate. MCP has no concept of agent discovery ("what agents exist and what can they do?"), task delegation ("handle this job and get back to me"), or opaque execution ("I don't need to know how you solved it, just give me the result"). For that, you need A2A. For a deeper understanding of MCP's architecture, see our introduction to the Model Context Protocol.
A2A: The Agent-to-Agent Layer
Google released the Agent-to-Agent protocol in April 2025 and donated it to the Linux Foundation two months later. By early 2026, A2A v1.0 shipped with production-grade features — gRPC support, signed Agent Cards, and Python SDK — and over 150 organizations have adopted it, including Microsoft, AWS, Salesforce, SAP, and ServiceNow.
A2A solves a fundamentally different problem than MCP: how do autonomous agents discover each other, delegate work, and collaborate without exposing their internals?
{
"name": "fraud-detection-agent",
"description": "Analyzes transactions for fraud patterns",
"url": "https://agents.internal/fraud",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"inputModes": ["application/json"],
"outputModes": ["application/json"]
}Agent Cards: Discovery Without Exposure
Every A2A-compatible agent publishes an Agent Card — a JSON document that describes what the agent can do, what inputs it accepts, what outputs it returns, and how to authenticate. Client agents fetch these cards to find the right agent for a task. Critically, the card doesn't reveal how the agent works internally. It's a capability advertisement, not a schema dump. This is the key difference from MCP. When your agent calls an MCP tool, it knows the tool's parameters and controls the execution. When your agent delegates to an A2A agent, it's hiring a contractor — "analyze this transaction batch for fraud" — and the contractor decides how to do it. The fraud detection agent might use its own MCP tools, its own models, its own reasoning chain. The delegating agent doesn't know or care.
Task Lifecycle
A2A tasks have a proper lifecycle: submitted, working, input-required, completed, failed, or canceled. This matters for long-running operations. A compliance review might take minutes. A report generation agent might need to ask clarifying questions mid-task. A2A handles all of this through a task object that both agents can reference and update. Communication happens over JSON-RPC 2.0 on HTTP, with optional gRPC for high-throughput scenarios. Agents can stream partial results via SSE or receive push notifications when long-running tasks complete.
When You Need A2A
You need A2A when your agents cross trust or organizational boundaries. If the compliance agent and the fraud agent are both in your codebase, sharing the same database, you can orchestrate them with function calls. But when the fraud agent is a third-party service, when agents are built on different frameworks (one on LangGraph, another on Google ADK, another on Strands), or when agents need to discover each other dynamically in a multi-tenant environment — that's where A2A earns its complexity. We covered the broader multi-agent orchestration challenge in our guide on orchestration patterns that actually ship. A2A doesn't replace those patterns — it provides the communication layer that makes cross-boundary orchestration possible. For a comparison of the cloud agent platforms that implement these protocols natively, see our breakdown of Google ADK vs AWS Strands.
AG-UI: The Agent-to-User Layer
AG-UI is the newest and least understood protocol in the stack. Created by CopilotKit, it has crossed 9,000 GitHub stars and was adopted by AWS Bedrock AgentCore in March 2026, Google ADK, and Microsoft's Agent Framework 1.0.
AG-UI solves the "last mile" problem: how do you stream what an agent is doing into a user-facing application — not as a chat transcript, but as a rich, interactive experience?
The state management events are the differentiator. STATE_SNAPSHOT delivers the complete agent state at a point in time. STATE_DELTA sends only what changed, using JSON Patch operations. This means your frontend stays in sync with the agent without polling, without full refreshes, and without custom WebSocket message parsing.
Why Chat Isn't Enough
Most agent UIs today are chat interfaces. The user sends a message. The agent responds. Maybe there's a typing indicator. This works for simple Q&A but falls apart when agents perform complex, multi-step operations. When our fintech compliance agent is reviewing 500 transactions, the compliance officer doesn't want to wait for a final chat message. They want to see which transaction is being analyzed, which tools are being called, whether the sanctions list check passed or failed, and whether they need to approve an escalation — all in real time. That's not a chat problem. That's a state synchronization problem.
The Event Stream
AG-UI defines approximately 17 typed events that flow from agent backend to frontend over HTTP SSE or WebSocket:
What AG-UI Replaces
Without AG-UI, every team building an agent-powered UI writes custom plumbing: a WebSocket server that streams custom JSON messages, a frontend parser that interprets them, state reconciliation logic to handle out-of-order events. We've built this custom layer at least a dozen times for clients. Every implementation was different, every one had edge cases around reconnection and state consistency, and none were reusable. AG-UI replaces all of that with a standard event protocol and SDKs in TypeScript and Python. You implement an AG-UI-compatible endpoint on your backend, drop in the frontend SDK, and get streaming text, tool call tracking, and state synchronization out of the box.
| Event Category | Events | What It Covers |
|---|---|---|
| Text Messages | START, CONTENT, END | Streaming text token by token |
| Tool Calls | START, ARGS, END, RESULT | Full tool execution lifecycle |
| State Management | SNAPSHOT, DELTA | Full state + incremental JSON Patch (RFC 6902) |
| Run Lifecycle | STARTED, FINISHED, ERROR | Agent execution boundaries |
| Activity | SNAPSHOT, DELTA | Progress tracking and status |
All Three Working Together
Here's how the three protocols compose in a real architecture — using the fintech compliance system as an example:
┌─────────────────────────────────────────────────────┐
│ Compliance Dashboard (React) │
│ ← AG-UI events (text, tool calls, state deltas) ← │
└────────────────────────┬────────────────────────────┘
│ AG-UI
│
┌────────────────────────▼────────────────────────────┐
│ Compliance Agent (orchestrator) │
│ ├─ MCP → KYC Database Server │
│ ├─ MCP → Sanctions List Server │
│ ├─ A2A → Fraud Detection Agent (third-party) │
│ └─ A2A → SAR Filing Agent (internal, LangGraph) │
└─────────────────────────────────────────────────────┘The compliance agent uses MCP to query its tools (KYC database, sanctions lists). It uses A2A to delegate fraud analysis to a specialized agent that might be running on a different framework, in a different cloud account. And it uses AG-UI to stream every decision, tool result, and escalation request to the compliance officer's dashboard in real time.
No protocol overlaps. No custom translation layers. Each handles its layer.
The Decision Framework
Not every agent system needs all three protocols. Here's how to decide what you need based on your architecture's complexity:
Start With MCP
If you're building any agent that interacts with external systems, MCP is non-negotiable. The ecosystem is too large and the protocol too established to ignore. Wrap your services in MCP servers, connect your agents, and move on to harder problems.
Add A2A When You Hit the Boundary
You need A2A when two conditions are true: you have multiple agents, and those agents can't share internals directly. Same-team agents in the same repo often don't need A2A — regular function calls or framework-level orchestration (LangGraph sub-agents, ADK Sequential/Parallel agents) handle coordination fine. A2A earns its weight when agents are independently deployed, independently developed, or owned by different organizations.
Add AG-UI When Chat Isn't Enough
If your agent's output is just text responses in a chat window, you don't need AG-UI. If you need to show tool execution progress, synchronize shared state between agent and UI, support human-in-the-loop approval flows, or stream structured data (not just text) — AG-UI is the clean path. The alternative is building custom WebSocket plumbing that you'll maintain forever.
| Architecture Level | What You're Building | Protocols Needed |
|---|---|---|
| Single agent + tools | One agent calling APIs, databases, file systems | MCP only |
| Single agent + UI | Agent-powered app with streaming, progress, approvals | MCP + AG-UI |
| Multi-agent internal | Multiple agents in the same codebase, same team | MCP + direct orchestration |
| Multi-agent cross-boundary | Agents across frameworks, teams, or organizations | MCP + A2A |
| Full production system | Multi-agent with interactive user-facing dashboard | MCP + A2A + AG-UI |
The Convergence Signal
The strongest signal that this three-protocol stack is becoming the standard: AWS Bedrock AgentCore Runtime now supports all three. MCP for tools, A2A for inter-agent coordination, AG-UI for frontend streaming. Google's ADK supports MCP and A2A natively, with an AG-UI integration released in early 2026. Microsoft's Agent Framework 1.0 supports MCP and AG-UI.
The Agentic AI Foundation under the Linux Foundation — co-founded by Anthropic, OpenAI, and Block — provides neutral governance for MCP. A2A has its own Linux Foundation home. AG-UI remains community-governed through CopilotKit but has the cloud-provider adoption that typically precedes formal governance.
The "TCP/IP moment for agentic AI" framing that's gaining traction isn't wrong — it's just that the protocol stack has three layers, not one. MCP is the data layer. A2A is the coordination layer. AG-UI is the presentation layer. Like TCP/IP, you don't always need all of them. But when you do, having standard protocols at each layer beats building custom plumbing every time.
If you're designing a multi-agent architecture, understanding the communication patterns between agents is just as important as picking the right protocols. The protocols define how agents talk — the patterns define what they say.
Frequently Asked Questions
Quick answers to common questions about this topic
Each protocol operates at a different layer. MCP (Model Context Protocol) handles agent-to-tool communication — how an agent discovers and invokes external tools, databases, and APIs. A2A (Agent-to-Agent) handles inter-agent coordination — how agents delegate tasks, share context, and collaborate while keeping their internals opaque. AG-UI (Agent-User Interaction) handles the frontend layer — how agent backends stream text, tool call progress, reasoning steps, and state updates to user-facing applications in real time. They are complementary, not competing.
