A customer opens a support chat and types one sentence: "Refund my order from yesterday."
No menus. No buttons. The Agent understands, and the work begins. In moments like this, natural language feels like the only user interface an Agent will ever need.
But watch what happens next.
The customer wants to scan fifteen orders at once. They want to adjust a quantity, compare two receipts, and give a final confirmation before money moves. Suddenly typing sentences feels slow — and the Agent UI needs buttons, lists, and cards after all.
The simplest way to talk to an Agent is not always the most efficient way to work with one. In production AI systems, the engine and the harness matter, but a well-designed frontend remains indispensable, especially for user-facing AI-native apps.
Three standards have emerged around this problem: AG-UI, A2UI, and MCP Apps. They sound similar. They are not competing copies. Each one solves a different layer of the Agent UI puzzle.
One Sentence Isn't a User Interface: What Agent UI Changes
Natural language cannot replace traditional UI.
Expressing a task in words is powerful. "Refund my order from yesterday" beats hunting through menus. But reading a dozen orders is faster in a list, changing a quantity is faster with an input or a slider, and confirming an action is faster with a button than typing "I'm sure."
So an Agent UI is usually a hybrid: natural language for intent, graphical interface for precision.
When an Agent and a human exchange complex information repeatedly, the visual expressiveness of HTML beats a wall of plain text or Markdown. Think of a customer-service workbench with a streaming reply and live status panels.
Agents need a UI that moves with the task.
A traditional app is designed in advance: search, order list, order detail, confirmation, success. The user follows a fixed route.
An Agent's route is not fixed. Which tool runs first, what information is missing, when a human must step in — none of this is guaranteed before the task starts. The interface therefore has to appear as the task demands: an address picker when an address is missing, an amount check when payment is involved.
The complexity runs deeper still.
An Agent task can run for minutes. The frontend must show more than replies — it must show progress: which tool is being called, how much is done, what artifact is being produced.
And when an Agent reaches an external system through MCP, a new question appears. If that integration needs continuous interaction — finding nearby restaurants and ordering from one, for example — where does the interface come from? Building every one of them by hand in the client creates heavy coupling.
AG-UI, A2UI, and MCP Apps each answer a piece of that question.
AG-UI: A Shared Vocabulary for Agent-Frontend Events
AG-UI, the Agent-User Interaction Protocol, was started by CopilotKit team, released publicly in May 2025, and reached a stable 1.0 specification by September 2026.
In one sentence, it is an open event standard for real-time, two-way, structured communication between an AI Agent and a user interface.
A frontend and an Agent constantly exchange signals: requests, replies, progress, confirmations. AG-UI standardizes the events, formats, and protocol behind those signals.
One boundary matters: AG-UI does not define the UI itself. It tells the frontend what happened — not how the card should look. Presentation stays entirely in the frontend's hands.
The flow works like this. The frontend submits a task, usually over HTTP POST. An AG-UI adaptation layer converts the Agent's output into standard events streamed back, typically over SSE: run started, run finished, step started, step finished, text message, text delta, state snapshot, tool call started, and more. User confirmations flow back to the Agent the same way.
The official 1.0 SDK supports TypeScript, Python, and .NET, with adapters for frameworks such as LangChain. On the frontend, teams can use CopilotKit or the standalone @ag-ui/client without replacing their UI framework.
Return to the refund example. At the confirmation step, the Agent should present a clear graphical refund card and capture the customer's decision.
The card is still built by the client. Only the communication follows AG-UI. Print the events the Agent sends and the point becomes clear: there are no UI elements in them, only facts about what is happening and the data those moments carry.
A2UI: The Agent Describes the Interface, the Frontend Renders It
A2UI, the Agent-to-User Interface protocol, is a declarative UI standard initiated by Google and published in December 2025, with CopilotKit and the broader community contributing.
Its purpose is to let a backend AI safely and dynamically drive the generation and updating of frontend interfaces across platforms.
This is the answer to the dynamic-UI problem. When a task needs an interface that does not exist in any fixed flow, A2UI carries a description of which controls are needed, how they are organized, and what data they bind to. The frontend then draws them with components it trusts.
The Agent decides what the UI should express. The frontend keeps control over rendering, styling, and capabilities.
The backend sends JSON describing surfaces, components, and data. A frontend renderer validates that description against a component catalog, maps each component to a local control, and renders it. When the user clicks, an action travels back through the frontend to the backend, which returns updated UI messages.
