For about two years, building an agent application meant solving the same plumbing problem twice and then giving up on a third. The first was tools: how does the model reach a database, an API, a file? The second was orchestration: how do several agents hand work to each other? Both of those got standards — MCP for the first, A2A for the second — and the industry exhaled. But there was a third hop nobody standardized, and it was the one your users actually see: how does the agent, churning away on a server, show its work to the human watching the screen?
That hop was the last mile of agent UX, and until recently every team paved it alone. You wrote a bespoke server-sent-event format to stream tokens. You invented your own message shape to push "calling the search tool…" into the chat bubble. You hand-rolled the logic to pause the run, surface an approval dialog, and resume. Then the next team did it all again, incompatibly, and so did the framework you switched to. AG-UI — the Agent-User Interaction Protocol — is the standard that finally names this layer.
Three protocols, three hops, no overlap
The cleanest way to hold the stack in your head is to ask what each protocol connects.
- MCP connects an agent to tools and data — the database query, the API call, the file read. Request, response.
- A2A connects an agent to other agents — discovery, delegation, the long-lived collaboration where one agent farms a subtask to another.
- AG-UI connects the agent backend to the user-facing frontend — the streaming chat, the live tool-call status, the human-in-the-loop approval.
They're not competitors fighting over the same territory. They're three segments of one wire, and a single app commonly speaks all three: pull context over MCP, delegate over A2A, stream the result over AG-UI.
The mistake is reading them as alternatives because the acronyms rhyme. They don't substitute; they compose. An agent answering a support ticket might fetch the customer's history through MCP, loop in a billing specialist agent through A2A, and narrate the whole thing to the user in real time through AG-UI.
What AG-UI actually is
AG-UI is an open, lightweight, event-based protocol. Instead of the frontend polling or the two sides exchanging unstructured WebSocket blobs, the agent backend emits a stream of typed events and the frontend consumes them as they arrive. The protocol defines roughly 16 standard event types across five families: lifecycle (a run starting and finishing), text messages (streaming deltas of the response), tool calls (which function the agent is invoking and its result), state (syncing shared data between agent and UI), and special events (pausing for human approval, or custom needs).
That event vocabulary is the whole point. Once "the agent started a tool call" is a named event with a defined shape rather than a string you invented, any compliant frontend can render it — a progress chip, a spinner, an inline diff — without knowing which framework produced it. AG-UI is deliberately transport-agnostic: the same event stream rides over Server-Sent Events, WebSockets, or webhooks, with a reference HTTP implementation in the box. It standardizes the grammar of agent-to-user communication and leaves the pipe to you.
The tell: rivals agreed on the same frontend
Protocols live or die by adoption, and AG-UI's adoption curve says something specific. The project crossed 14k GitHub stars inside a year, and its maker, CopilotKit, raised $27M in 2026 as the protocol spread. But the stars aren't the interesting number. The interesting number is the list of adopters, because it reads like a roster of frameworks that agree on almost nothing else.
LangGraph and CrewAI — which model agent control flow in opposite ways — both support it. So do Google's ADK, Microsoft's Agent Framework, AWS's Strands Agents, Pydantic AI, Agno, LlamaIndex, and AG2, with the Claude Agent SDK in the community tier and OpenAI's Agent SDK, Bedrock Agents, and Cloudflare Agents listed as in progress. These projects compete fiercely on how you build an agent — the graph, the crew, the conversation, the durable loop. They have now quietly converged on the same answer for how that agent should talk to a screen.
That convergence is the signal worth reading. When companies that disagree about everything in their core product adopt an identical protocol at the edge, it means the edge was never their differentiator — it was shared infrastructure everyone was duplicating at a loss. MCP revealed that about tool access; A2A about agent collaboration; AG-UI reveals it about the frontend. The agent-to-human connection was never where anyone wanted to compete. It was just the last piece of the stack that hadn't been handed a standard yet.
What it means for what you build
If you're shipping an agent with a UI in 2026, the practical takeaway is to stop writing your own streaming protocol. Pick a framework that speaks AG-UI on the backend and a frontend that consumes it, and you inherit streaming chat, live tool-call rendering, shared state, and human-in-the-loop approval as a wire format rather than a pile of bespoke event handlers you maintain forever. The same way you stopped writing per-provider tool adapters once MCP existed.
The larger pattern is that the agent stack is finishing its standardization from the inside out. Tools first, agents second, users last — each hop converted from custom glue into a protocol the moment the industry agreed it wasn't worth re-inventing. Three protocols, three hops, and now the one your users actually look at has a name too.
