A2UI Explained: What the Agent-to-UI Protocol Does (and Doesn't) Do
A2UI is a declarative JSON protocol that lets AI agents describe interfaces for a client to render. How it works, which renderers exist, and what it does not do.
Core Takeaway
A2UI (Agent to UI) is an open, declarative JSON protocol created by Google. An AI agent sends a description of an interface, and a client renders it with its own native components instead of executing code from the agent. It is a way to move UI structure and data across a trust boundary, not an animation system, a component library or a finished renderer. ExodeUI is not an A2UI renderer and is not affiliated with Google.
What is A2UI?
A2UI is a protocol for agent-driven interfaces. Instead of returning a wall of text or executing generated code, an AI agent sends a stream of JSON messages that describe a UI: which surface to create, which components it contains, and what data fills them. The client receives those messages and renders the result with components it already trusts. A2UI was created by Google and is Apache 2.0 licensed, with contributions from CopilotKit and the open-source community. As of October 2026, the current production specification was v0.9.1 and v1.0 was a release candidate.
The problem A2UI is trying to solve
Agents are good at producing a useful answer and bad at delivering it as an interface. A text response cannot show a comparison table, an order form or a dashboard. Generating arbitrary HTML or JavaScript solves the presentation problem and creates a security one, because the client is now running code it did not write. A2UI takes a third route: the agent describes the UI in a constrained format, and the client decides how to render it. The agent can only use components the client has approved, and the output is data rather than executable code.
How an A2UI surface is built
The protocol uses a small set of message types. The exact schema changes between versions, so check the specification before implementing one, but the shape is stable.
- createSurface: tells the renderer to create a new surface, which is a region of the interface the agent can update
- updateComponents: adds or changes component definitions on that surface
- updateDataModel: changes the data the components display, without resending the structure
- deleteSurface: removes a surface when it is no longer needed
Renderers and transports
A2UI is transport-agnostic. The specification describes the messages, not how they travel. The project lists renderer implementations for Angular, Flutter, Lit, React and Markdown, and transport bindings for AG-UI, A2A and MCP, with WebSockets, SSE and REST also usable. That flexibility is the point: the same agent response can be rendered by a web client, a mobile app or a desktop application, each using its own design system.
What A2UI does not do
A2UI is easy to over-read. It does not ship a component library you can drop into an app, and it does not render anything by itself: you need a renderer and a component catalog that the client controls. It does not decide how the UI moves. It does not replace MCP, which exposes tools and data to a model, or AG-UI, which carries the interaction events between an agent and a frontend. And it does not remove the need for engineering review: generated interfaces still have to handle loading, empty and error states, permissions and accessibility.
A2UI vs AG-UI vs MCP
These three are often mentioned together because they solve different layers of the same problem. A useful shorthand: A2UI describes the interface, AG-UI carries the interaction, and MCP gives the agent tools and data. A2UI's own documentation describes AG-UI as a transport binding for A2UI, and A2UI can also travel over MCP. They are complementary, not competing standards. If you are choosing an integration, start from what your client can render and which transport it already supports, not from the protocol with the most momentum.
Where animation and interaction fit
A2UI describes structure and data. Motion is a client concern: the renderer decides whether a surface appears instantly, fades in or transitions from a previous state. That is good news for product teams, because it keeps the animation system in the client where it can respect the design system and accessibility settings. It also means an A2UI implementation is not automatically animated. If a generated interface needs a button press, a state transition or a mascot reaction, the client has to provide that behaviour. ExodeUI can play interactive motion in a client, and it has an MCP server for AI coding tools, but it is not an A2UI renderer and should not be described as one.
Production Implementation Snippet
// Simplified shape of an A2UI message stream (schema differs by version).
{ "createSurface": { "surfaceId": "cart" } }
{ "updateComponents": { "surfaceId": "cart", "components": [ /* ... */ ] } }
{ "updateDataModel": { "surfaceId": "cart", "data": { /* ... */ } } }
{ "deleteSurface": { "surfaceId": "cart" } }Key Principles to Remember
- A2UI is a JSON protocol for agent-described interfaces, created by Google and licensed under Apache 2.0
- The client renders with its own components; the agent does not execute arbitrary UI code
- It defines messages and leaves the renderer, transport and motion to the client
- It is not an animation system or a drop-in component library
- ExodeUI is not an A2UI renderer and has no affiliation with Google