The three protocols get compared constantly and the comparison is usually a category error. Each one standardizes a different wire out of the agent. Using the vocabulary of the three buckets of the agentic world: MCP and A2A live in the orchestration bucket, where agents act and coordinate, and AG-UI is the signature protocol of the agent-user connectivity bucket, where agents meet the people they work for.
What is MCP?
MCP, the Model Context Protocol, connects agents to tools and data. Anthropic introduced it in November 2024, and in December 2025 donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation.
MCP is a client-server protocol built on JSON-RPC. An MCP server wraps a capability (a database, an API, a file system, a SaaS product) and exposes three kinds of things: tools the agent can call, resources it can read, and prompts it can reuse. The agent’s side, the MCP client, discovers what a server offers and invokes it. The payoff is an N-to-one integration story: write one MCP server for your system and every MCP-compatible agent can use it, instead of every agent framework shipping its own connector.
MCP answers the question “how does my agent reach the things it acts on?” It says nothing about how the agent talks to other agents, and, with one scoped exception covered below, nothing about how it talks to users.
What is A2A?
A2A, the Agent2Agent protocol, connects agents to other agents. Google announced it in April 2025 at Google Cloud Next and donated it to the Linux Foundation in June 2025, where it is governed as a vendor-neutral standard with backing from Microsoft, AWS, Salesforce, SAP, and over a hundred other organizations.
A2A specifies how independently built agents discover and work with each other. Each agent publishes an Agent Card describing its capabilities; peers use it to find the right agent, then delegate work through a defined task lifecycle, exchanging messages and artifacts over JSON-RPC on HTTP with server-sent events for streaming. The point is interoperability across vendors: a claims-processing agent from one company can hand a subtask to a fraud-detection agent from another without either knowing the other’s internals.
A2A answers the question “how does my agent reach other agents?” Both parties on an A2A wire are programs.
What is AG-UI?
AG-UI, the Agent-User Interaction protocol, connects agents to users and their applications. CopilotKit introduced it in May 2025 under the MIT license, building it in the open with the agent framework ecosystem; it now has integrations across LangGraph, CrewAI, Mastra, Pydantic AI, the Google Agent Development Kit, Microsoft Agent Framework, AWS Strands, and others.
AG-UI exists because agents break request-response: they run for minutes, get steered mid-run, survive dropped connections, and mix text with structured data. AG-UI standardizes what the agent-to-user connection must carry as a stream of typed JSON events, grouped into lifecycle events, text message events, tool call events, state management events, and custom events, running over server-sent events, WebSockets, or plain HTTP.
Those events give applications the interaction patterns users actually experience: token-by-token streaming, bi-directional shared state between agent and app, human-in-the-loop approvals, and generative UI, where the agent’s output renders as live interface rather than prose.
AG-UI answers the question “how does my agent reach the person it works for?”
MCP vs. AG-UI
MCP points inward from the agent; AG-UI points outward. The differences follow from who sits on the other end of the wire:
- Other party. MCP terminates at a server wrapping a tool or data source. AG-UI terminates at a human inside an application.
- What travels. MCP carries tool definitions, invocations, and results. AG-UI carries token streams, state patches, interrupts, approvals, and UI payloads.
- Interaction shape. MCP calls are discrete: invoke, get a result. AG-UI sessions are continuous: a long-running, steerable, resumable stream.
One agent routinely speaks both in a single run: it calls a CRM through MCP while streaming its progress to the user through AG-UI. The scoped exception where MCP touches UI is MCP Apps, an extension that lets an MCP server ship interactive UI into a host application’s chat surface. It handles that embedded case; it does not make MCP an agent-to-user protocol.
A2A vs. AG-UI
A2A and AG-UI look similar from a distance, since both connect an agent to a counterpart and both stream. The difference is the counterpart. On an A2A wire it is another program, so the protocol optimizes for what programs need: capability discovery through Agent Cards, formal task lifecycles, machine-readable artifacts. On an AG-UI wire it is a person, so the protocol optimizes for what people need: readable streams, interfaces that render, the ability to interrupt and redirect, and approval gates before consequential actions.
The two meet in multi-agent systems. When your agent delegates to a peer over A2A, the user still watches and steers that work through one AG-UI connection: the sub-agent’s activity surfaces back through the same stream, so the human sees one coherent session rather than one window per agent.
Do you need all three?
Eventually, most production systems do, because the protocols compose rather than compete. Consider a single run of a support agent inside a SaaS product:
- The user asks a question in the app, and the session opens over AG-UI.
- The agent pulls the customer’s history from the CRM through MCP.
- It delegates a billing question to a specialist finance agent over A2A.
- It streams progress, shares state with the app, and asks the user to approve the refund, all over the same AG-UI connection.
In bucket terms: MCP and A2A both live in orchestration (how the agent acts and coordinates), AG-UI lives in agent-user connectivity (how the agent faces people). Adoption tends to follow the agent’s growth: MCP when it needs capabilities, AG-UI when it needs users, A2A when it needs peers.
Where does A2UI fit?
A2UI is the name most often mistaken for a fourth protocol. It is not one. A2UI is a declarative generative UI specification originated by Google: a format in which an agent describes the interface it wants rendered as a structured payload of components, which the receiving application renders with its own native widgets. A specification for messages, not a wire: A2UI payloads are transport-agnostic and ride over a protocol like AG-UI, which carries them from the agent into the application.
In the vocabulary of generative UI’s three pillars (controlled, declarative, and open), A2UI is a specification within the declarative pillar. The pairing is covered in depth in AG-UI and A2UI: A2UI defines what the interface is, AG-UI delivers it and everything else the session needs.
