MCP vs. A2A vs. AG-UI: the agent protocol stack, explained with one diagram

Three protocols keep showing up in agentic architectures, and they are not competitors. They own three different boundaries of the same system. Here is the whole picture:

%% caption: Three protocols, three boundaries — AG-UI to people, MCP to tools, A2A to other agents
flowchart TB
    U["User<br/>browser or app"]:::human -- "AG-UI<br/>agent ↔ user" --> A1
    subgraph org1 ["Your system"]
        A1["Agent A<br/>orchestrator"]:::agent
        A1 -- "MCP<br/>agent ↔ tools" --> T1["Tools: DB, files, APIs"]:::system
    end
    A1 -- "A2A<br/>agent ↔ agent" --> A2
    subgraph org2 ["Another team or vendor"]
        A2["Agent B<br/>specialist"]:::agent
        A2 -- "MCP" --> T2["Its own tools"]:::system
    end

The one-sentence version of each

MCP (Model Context Protocol) connects an agent downward to tools and data. It answers: how does my agent call things? (Build one in your first MCP server.)

A2A (Agent2Agent) connects an agent sideways to other agents — possibly built by other teams on other stacks. It answers: how do two agents that don’t share a codebase delegate work to each other? Each A2A agent publishes an Agent Card describing what it can do; there’s a starter in the templates.

AG-UI connects an agent upward to the human interface — streaming state, intermediate steps, and interactive components to a frontend. It answers: how does the user watch and steer a running agent?

Why the layers don’t overlap

The temptation is to pick “the winner.” But the protocols differ in what they assume about the other side:

A useful test: if you can describe the counterparty’s behavior with a JSON schema, it’s a tool — use MCP. If the counterparty needs to plan, ask clarifying questions, or refuse, it’s an agent — that boundary is A2A.

Where they overlap: MCP Apps and AG-UI

The table above is the clean version. In practice there is one real overlap. MCP Apps is an official MCP extension that lets a tool return an interactive HTML interface (served as a ui:// resource and rendered in a sandboxed iframe by the host app). So an MCP server can now put UI in front of the user, which sounds like AG-UI’s job.

They still sit at different boundaries:

• MCP Apps is a tool shipping its own widget into whichever host calls it: a chart, a form, a confirmation dialog inside the chat. The host (Claude, ChatGPT, VS Code and others) owns the conversation; the tool owns one panel.
• AG-UI is your agent streaming its run (messages, tool calls, state changes, reasoning) to your frontend. You own the whole interface.

Rule of thumb: building a tool that should look good in other people’s agent apps? MCP Apps. Building your own product UI on top of your own agent? AG-UI.

Where each protocol stands (as of October 2026)

So MCP and A2A now sit in the same neutral foundation, alongside AGENTS.md. If you are upgrading an existing MCP server for the 2026-07-28 revision, follow migrate an MCP server to the 2026 spec. For how MCP Tasks and A2A tasks differ when work runs for minutes or hours, see long-running agent tasks.

The decision rule

1. Start with MCP only. A single agent with good tools covers most use cases.
2. Add AG-UI (or an equivalent event stream) the moment a human needs to see more than the final answer — approvals, progress, partial results.
3. Add A2A last, and only when delegation crosses a real ownership boundary — another team, another vendor, another trust zone. Inside one codebase, plain function calls between your agents beat a protocol.

Where to go next

See the protocols in a running system in multi-agent orchestration, or check where they sit in the full agentic AI tech stack.