The 2026 agent protocol stack is four layers, and they do not compete. MCP connects an agent to tools, A2A connects an agent to other agents, AG-UI streams an agent's activity to a frontend, and A2UI lets an agent describe a UI for the client to render. If you remember one thing: this is TCP/HTTP/HTML — different jobs at different heights — not a format war where one winner eats the others. Pick the layer that matches your problem; you will often run several at once.
The one genuinely new entry this cycle is A2UI, an agent-to-UI spec Google introduced in December 2025 (Google Developers Blog). It sits next to AG-UI, not on top of it, and founders keep conflating the two. The bulk of this guide is about telling them apart.
Four protocols, four layers, zero overlap. The mistake is treating them as a bracket instead of a stack.
The stack, one layer at a time#
MCP (Model Context Protocol) — agent ↔ tools. Introduced by Anthropic in November 2024, MCP is the layer that lets an agent call external tools and read external data through a single standard interface, over JSON-RPC. It exists to kill the M×N integration problem: instead of hand-wiring every model to every tool, you implement the client once and the server once (Anthropic). It is now the de-facto standard for agent-to-tool wiring, adopted across OpenAI, Google, and Microsoft (Wikipedia). If your agent needs to hit your database, your CRM, or a third-party API, this is your layer. For the difference between MCP and plain tool-calling, see our MCP vs function calling piece.
A2A (Agent2Agent) — agent ↔ agent. Launched by Google Cloud with 50+ partners and now governed under the Linux Foundation, A2A is how independent agents discover and delegate to each other. Its core primitive is the Agent Card — a machine-readable description of what an agent can do — plus a task/message model for coordination. A2A reached v1.0 in 2026. You need it the moment you have more than one agent, especially agents built by different teams or vendors that have to interoperate. We cover the mechanics in A2A vs MCP and the practical expose/consume pattern in the Microsoft Agent Framework A2A walkthrough.
AG-UI (Agent-User Interaction) — agent ↔ frontend. Built by CopilotKit (with LangGraph and CrewAI), AG-UI is an open, event-based protocol that standardizes the live stream between a running agent and a user-facing app (GitHub). It defines roughly 16 standard event types — streaming text, tool-call start/end, state updates, and UI surface events — so your frontend can render what the agent is doing in real time without a bespoke WebSocket layer. Think of it as the transport that keeps agent and app in sync. Our earlier AG-UI vs MCP vs A2A breakdown maps the first three layers in depth.
A2UI (Agent-to-UI) — agent ↔ rendered interface. This is the new one, and it is a different job from AG-UI. Where AG-UI is the pipe, A2UI is the content that can flow through it.
AG-UI vs A2UI: the distinction that trips everyone up#
Here is the cleanest way to hold it: AG-UI is the transport, A2UI is the payload. AG-UI describes how messages move between agent and app. A2UI describes what UI to render (CopilotKit).
A2UI is a declarative UI specification. When an agent wants to show something to a user, it does not emit HTML or JavaScript — it emits a JSON payload describing components (a Card, a Button, a TextField), their properties, and a data model. The client app reads that description and maps each component to its own native widgets, so the same A2UI response renders on web (React, Angular, Lit), mobile (Flutter, SwiftUI, Jetpack Compose), and desktop.
Two design choices matter for founders:
- It is data, not code. The client keeps a catalog of trusted, pre-approved components, and the agent can only request things from that catalog. An LLM cannot inject arbitrary executable UI — a real security property when the interface is model-generated.
- It is LLM-friendly. The UI is represented as a flat list of components with ID references rather than a deep nested tree, which is easy for a model to generate incrementally and stream progressively.
A2UI is open-source (Apache 2.0) on GitHub, still pre-1.0 (the v0.9 line), with CopilotKit as a launch partner — which is why AG-UI can already carry A2UI payloads. That partnership is the tell: they are not rivals. AG-UI is the pipe; A2UI is one thing you can send through it.
AG-UI answers "how does the agent talk to my app?" A2UI answers "what does the agent want my app to show?"
When a founder actually needs A2UI vs AG-UI#
Most teams reach for the wrong one because the names rhyme. Use this:
- You built the frontend and want the agent to drive it live — streaming tokens, showing tool progress, syncing state, handling human-in-the-loop approvals. That is AG-UI. You already own the components; you just need a standard event stream.
- You want the agent itself to decide what interface to show at runtime — a form whose fields depend on the conversation, a results card the model composes on the fly, UI that varies per user and per turn. That is A2UI. The agent is now a UI author, and you need a safe, declarative way to render what it invents.
- You want both — the common production case. Use AG-UI as the transport and let it carry A2UI payloads when the agent needs to render generative UI. They compose cleanly.
If your interface is fixed and you only need the agent's behavior surfaced, you do not need A2UI at all. A2UI earns its place specifically when the interface is dynamic and model-authored. Do not add it for the novelty; add it when static components genuinely cannot express what the agent needs to show.
The decision, made plainly#
- Agent needs to use tools or data? → MCP. Non-negotiable first layer; start here.
- More than one agent, especially across teams or vendors? → A2A. Add it when you actually have agents to coordinate, not before.
- Live agent activity in a frontend you own? → AG-UI. The transport for streaming, state sync, and human-in-the-loop.
- Agent should generate the UI itself at runtime? → A2UI. Declarative, catalog-safe, framework-agnostic — reach for it last, and only when static UI can't do the job.
- Mental model: MCP / A2A / AG-UI / A2UI are TCP / HTTP / HTML for agents. Different layers, built to compose. Almost every real agent product ships two or more of them together.
