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:

flowchart TB
    U["User (browser / app)"] -- "AG-UI<br/>agent ↔ user" --> A1
    subgraph org1 ["Your system"]
        A1["Agent A<br/>(orchestrator)"]
        A1 -- "MCP<br/>agent ↔ tools" --> T1["Tools: DB, files, APIs"]
    end
    A1 -- "A2A<br/>agent ↔ agent" --> A2
    subgraph org2 ["Another team / vendor"]
        A2["Agent B<br/>(specialist)"]
        A2 -- "MCP" --> T2["Its own tools"]
    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?

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?

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:

	MCP	A2A	AG-UI
Peer on the other side	A tool server (deterministic)	Another agent (autonomous)	A UI (human attached)
Conversation shape	Request → result	Task with lifecycle, negotiation	Event stream to render
Trust model	You usually run the server	Often crosses org boundaries	Same product surface
You need it when…	The agent must do things	Work must be delegated	A human must watch/steer

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.

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.

Troubleshooting

”Should I wrap my other agent as an MCP tool instead of using A2A?”

You can — and inside one team it’s often the pragmatic move. You lose task lifecycle semantics (progress, cancellation, multi-turn negotiation). If the sub-agent’s work is long-running or needs clarifying questions, that loss will hurt; if it’s effectively a smart function, wrap it.

”We picked A2A/AG-UI and the ecosystem shifted under us”

Protocols at the agent layer are still consolidating. Keep the coupling thin: isolate protocol adapters at the edges of your system so a swap is an adapter rewrite, not an architecture rewrite. (This is also just good hexagonal design.)

Next in this learning path Claude Code from zero: an agentic coding workflow, step by step →