Agent Protocols: A2A, AG-UI, and the Protocol Landscape
How agents talk to other agents (A2A) and to user interfaces (AG-UI) — plus the emerging '3 protocols, one stack' landscape alongside MCP.
Formulate task objective
Task: Fetch active users and generate database summary report.
▶📚 Prerequisites(2)
🎓 Learning objectives
- •Distinguish what MCP, A2A, and AG-UI each standardize (tool access, agent-to-agent, agent-to-UI)
- •Explain how AgentCards enable capability discovery in A2A
- •Describe the AG-UI event types that stream agent state to a frontend over SSE
- •Explain why these three protocols are complementary layers of one stack rather than competing standards
What is it?
These are two of the newest agent interoperability protocols, which together with MCP form what's often called 'the agent protocol stack.' A2A (Agent2Agent) lets AI agents connect to and collaborate with other AI agents — agents exchange context, task updates, instructions, and data without directly sharing internal memory, thoughts, or tools. AG-UI (Agent-User Interaction Protocol, built by CopilotKit) standardizes the real-time streaming connection between a backend agent and a frontend UI — solving the problem of every agent framework inventing its own bespoke WebSocket/streaming format. Where MCP standardizes agent-to-tool communication, A2A standardizes agent-to-agent communication, and AG-UI standardizes agent-to-user communication — three distinct legs of the same interoperability problem.
Why it exists
As agentic applications matured beyond single-agent demos, three separate integration problems emerged that MCP alone couldn't solve. First: how do multiple agents — possibly built with different frameworks (LlamaIndex, CrewAI, custom) — discover and collaborate with each other without hardcoding integrations between every pair? A2A exists to answer this. Second: once you have a working multi-step agentic backend (in LangGraph, CrewAI, Mastra, or anything else), how do you connect it to a real frontend without hand-building a custom WebSocket server, streaming logic, and UI adapters specific to that one backend — logic you'd have to redo entirely if you ever switched frameworks? AG-UI exists to answer this, standardizing the interaction layer so the frontend never needs to know which backend framework is running underneath.
Problem it solves
Without A2A, connecting N different agents (possibly from different vendors/frameworks) requires custom point-to-point integration code between every pair — an M×N-style integration explosion at the agent level, mirroring the exact problem MCP solved at the tool level. A2A solves this via a standard discovery mechanism (AgentCards) and communication protocol, so any A2A-compliant agent can find and work with any other. Without AG-UI, every agent backend (LangGraph, CrewAI, Mastra) has its own bespoke mechanism for tool-call visibility, ReAct-style planning display, state diffs, and output formats — meaning your frontend code is locked to one specific backend and has to be entirely rewritten if you migrate. AG-UI solves this by giving every backend a single standard way to stream structured events to any frontend, so migrating backends doesn't require touching the UI.
Intuition
Think of A2A like a business card exchange at a networking event — instead of every professional needing to know every other professional's entire resume in advance, everyone carries a standardized business card (an AgentCard) describing what they do and how to reach them, so any two people can quickly determine if and how to collaborate. Think of AG-UI like the difference between every airline having its own proprietary ticket format that only their own gate readers can scan, versus everyone adopting a standard barcode format that any airport's scanners can read — the moment there's one standard, any gate can serve any airline's tickets without custom hardware per airline.
Analogy
A2A is like a universal business-card format for AI agents — instead of hardcoding 'how do I talk to that specific agent,' every A2A-compliant agent publishes a standard JSON Agent Card describing its capabilities and authentication, so any other agent can discover and collaborate with it the same way, regardless of what framework built it. AG-UI is like the USB standard for peripherals — instead of every backend framework requiring its own custom 'port' (a bespoke WebSocket protocol) to talk to a UI, AG-UI is the single 'USB port' every backend can plug into, and every frontend can read from, without caring what's on the other end.
Technical explanation
A2A mechanics: an A2A-supporting Remote Agent publishes a JSON 'Agent Card' detailing its capabilities and authentication requirements. AI applications can model these A2A agents as MCP resources, represented by their AgentCard — meaning an agent connecting to an MCP server can discover new agents to collaborate with and then connect to them via the A2A protocol. This makes A2A and MCP complementary rather than competing: two agents might talk to each other via A2A, while each of those agents individually talks to its own tools via MCP. A2A enables secure collaboration, task and state management, capability discovery, and — critically — lets agents built on entirely different frameworks (LlamaIndex, CrewAI, etc.) work together.
AG-UI mechanics: it uses Server-Sent Events (SSE) to stream structured JSON events from a backend agent to a frontend, each with an explicit payload shape. Key event types include TEXT_MESSAGE_CONTENT (streams LLM output token by token), TOOL_CALL_START (surfaces tool execution progress as it happens), STATE_DELTA (efficiently syncs large, changing objects like code or tables without re-sending everything), and AGENT_HANDOFF (smoothly passes control between agents in a multi-agent system, visible to the UI). AG-UI ships with SDKs in TypeScript and Python, making it plug-and-play for any stack — a backend written in LangGraph, CrewAI, or Mastra can all emit the exact same AG-UI event format, and a frontend built once against AG-UI works against any of them, including swapping the underlying LLM (e.g., GPT-4 for a local Llama-3) with zero frontend changes.
Architecture
The 3-protocol landscape: MCP (Model Context Protocol) is the standard for how agents connect to tools, data, and workflows — started by Anthropic, now broadly adopted. A2A (Agent-to-Agent) is the protocol for multi-agent coordination — how agents delegate tasks and share intent across systems. AG-UI (Agent-User Interaction) is the bi-directional connection between agentic backends and frontends — how agents become interactive collaborators inside real apps rather than just chatbots. These aren't competing standards, they're layers of the same stack: AG-UI can handshake with both MCP and A2A, meaning tool outputs (from MCP) and multi-agent collaboration (via A2A) can flow seamlessly through to the user interface. CopilotKit sits above all three as an 'Agentic Application Framework' — the practical layer that lets you build with all three protocols, plus generative UI support and production-ready infrastructure, without dealing with each protocol's raw complexity directly.
Workflow
- If your system needs multiple agents (possibly from different frameworks) to discover and collaborate with each other, adopt A2A: define your agent's capabilities in a JSON Agent Card, and have it discover other agents' Agent Cards to determine who to collaborate with.
- If your system needs a real-time, interactive frontend on top of an agent backend (regardless of which framework built that backend), adopt AG-UI: have your backend emit AG-UI's standard SSE event stream (TEXT_MESSAGE_CONTENT, TOOL_CALL_START, STATE_DELTA, AGENT_HANDOFF) instead of building custom WebSocket logic.
- Layer these with MCP: your individual agents still use MCP to access their own tools/data, independent of how they talk to each other (A2A) or to the user (AG-UI).
- Consider CopilotKit if you want a ready-made application framework spanning all three protocols with generative UI components, rather than integrating each protocol from scratch.
- Validate framework portability as a design goal: if you switch your agent backend framework later (e.g., LangGraph to CrewAI), your AG-UI-based frontend and A2A-based multi-agent integrations should require zero or minimal changes.
Example
A2A: a minimal Agent Card (published by an A2A-compliant remote agent)
AGENT_CARD = { 'name': 'currency-analyst-agent', 'description': 'Provides real-time currency conversion and market analysis', 'capabilities': ['convert_currency', 'analyze_exchange_trends'], 'authentication': {'type': 'bearer_token', 'token_url': 'https://.../oauth/token'}, 'endpoint': 'https://agents.example.com/currency-analyst', }
AG-UI: example SSE events streamed from a backend agent to a frontend
import json
def emit_sse(event_type: str, payload: dict) -> str: return f'event: {event_type}\ndata: {json.dumps(payload)}\n\n'
Token streaming
emit_sse('TEXT_MESSAGE_CONTENT', {'delta': 'The converted amount is'})
Tool execution visibility
emit_sse('TOOL_CALL_START', {'tool': 'convert_currency', 'args': {'amount': 100}})
Efficient state sync (only the diff, not the full object)
emit_sse('STATE_DELTA', {'path': 'table.rows[3].total', 'value': 8420.50})
Multi-agent handoff, visible to the UI
emit_sse('AGENT_HANDOFF', {'from': 'router-agent', 'to': 'currency-analyst-agent'})
Real-world usage
CopilotKit, the creator of AG-UI, uses it to power its own generative-UI React component library, letting any LangGraph/CrewAI/Mastra backend stream directly into pre-built chat, tool-progress, and state-sync UI components without custom integration work. Enterprise multi-agent platforms building 'agent marketplaces' (where third-party agents can be discovered and composed into larger workflows) rely on A2A-style AgentCard discovery to let agents from different vendors interoperate safely. Companies building customer-facing agentic products (AI coding assistants, research copilots) that need to show live tool-execution progress, streaming responses, and human-interruptible workflows in their UI are the primary adopters of AG-UI, since building that streaming/state-sync infrastructure from scratch per framework is a significant engineering cost they'd rather avoid.
Trade-offs
Adopting these protocols adds a standardization layer and, for A2A in particular, real security/trust considerations — accepting task delegation from an unfamiliar agent requires verifying its Agent Card and understanding its authentication model, which is a genuinely harder problem than trusting a single, entirely self-built agent. AG-UI's benefit (framework portability for your frontend) is most valuable if you actually expect to change backend frameworks or need to support multiple backends simultaneously; for a simple, single-framework, single-agent app, hand-building a lighter custom streaming layer may be less overhead than adopting the full protocol. Both protocols are relatively new and still evolving, so committing to them means accepting some API/spec churn as the ecosystem matures.
Visual explanation
Three-layer stack diagram, bottom to top. Bottom layer: [MCP] — connects [Agent] to [Tools/APIs/Data]. Middle layer: [A2A] — connects [Agent 1] to [Agent 2] to [Agent 3], each potentially built on different frameworks, discovering each other via AgentCards. Top layer: [AG-UI] — connects the whole agent backend (regardless of framework: LangGraph/CrewAI/Mastra) to a [Frontend UI] via Server-Sent Events streaming structured JSON events (TEXT_MESSAGE_CONTENT, TOOL_CALL_START, STATE_DELTA, AGENT_HANDOFF). A wrapping box labeled [CopilotKit — Agentic Application Framework] sits around all three, providing generative UI components and production infrastructure that ties the stack together practically.
Advantages
- —
A2A solves the agent-to-agent integration explosion the same way MCP solved the agent-to-tool one, via standard discovery (AgentCards)
- —
AG-UI decouples your frontend from your specific backend framework choice — swap LangGraph for CrewAI or GPT-4 for a local model with zero frontend changes
- —
The three protocols (MCP, A2A, AG-UI) compose cleanly as layers of one stack rather than competing, so adopting one doesn't lock you out of the others
- —
AG-UI's SSE-based event streaming solves real, previously bespoke-per-framework UX problems: token streaming, tool-progress visibility, efficient state sync, and multi-agent handoff visibility
Disadvantages
- —
A2A introduces real trust/security considerations when accepting task delegation from agents you don't control
- —
Both protocols are new and still evolving, so early adopters should expect some spec/API churn
- —
Adopting AG-UI adds a standardization layer that's most valuable if you actually need framework portability — unnecessary overhead for a simple, fixed single-framework app
- —
Understanding the full 3-protocol landscape (plus how CopilotKit ties them together) has a real learning curve compared to just building a bespoke single-framework integration
Common mistakes
- —
Treating A2A and MCP as competing rather than complementary — A2A is for agent-to-agent, MCP is for agent-to-tool, and a single system commonly needs both simultaneously
- —
Hand-building custom WebSocket/streaming logic for a new agent frontend without first checking whether AG-UI already standardizes exactly what you need
- —
Accepting A2A task delegation from an unverified agent without properly validating its Agent Card's authentication claims
- —
Assuming AG-UI only works with CopilotKit's own UI components — the SDKs are framework-agnostic and can be wired into any custom React/frontend stack
- —
Adopting all three protocols prematurely for a simple single-agent, single-framework, single-frontend app where the interoperability benefits don't yet apply
📂 Subtopics
A2A Protocol: How Agents Discover and Collaborate with Other Agents
A2A lets AI agents connect to and collaborate with OTHER agents — distinct from MCP, which connects agents to tools. Agents publish a JSON "Agent Card" describing their capabilities so others can discover and communicate with them.
~15 min
AG-UI Protocol: Streaming Agent Execution to the Frontend
AG-UI standardizes the missing third leg of the agent stack — Agent-to-User communication — using Server-Sent Events to stream structured events like token generation and tool-call progress to any frontend.
~15 min
Why Protocols Matter: The Custom-Wiring Problem Without Standards
Before A2A and AG-UI, every agent-to-agent and agent-to-UI integration needed custom, framework-specific wiring — the same fragmentation problem MCP already solved for agent-to-tool integration, now solved for the other two connection points.
~12 min
A2A vs. AG-UI vs. MCP: Three Layers of the Same Stack
MCP, A2A, and AG-UI aren't competing choices — they answer three different questions (agent↔tools, agent↔agent, agent↔UI) and a real production system typically uses all three together.
~12 min