A2UI (Agent-to-User Interface) is an open protocol and framework that lets an AI agent answer with an interactive screen, such as a form to confirm or a chart, instead of only text. The agent sends a stream of JSON messages that describe the UI, and your app draws it with its own native components. Google announced A2UI 1.0, the first stable version, on November 11, 2026. It is Apache 2.0 licensed, with renderers for web, Android and iOS and agent SDKs for Python, TypeScript and Dart.
Why this is in the news
Google's Developers Blog post "A2UI 1.0: Build delightful, fast, reliable, agentic experiences" went up on November 11, 2026 and was posted to Hacker News. Search demand predates the release: Google autocomplete already suggests "a2ui protocol", "a2ui vs agui", "a2ui flutter", "a2ui examples" and "a2ui components". Autocomplete shows that people search those phrases, not how many do.
How A2UI works
The project's own one-line summary is that "the agent describes what to show, and every app draws the UI with its own native components." In practice there are four ideas to understand.
Surfaces
A surface is a region of UI that the agent creates, updates and deletes by sending messages. One surface might be a booking form inside a chat thread; another might be a results panel. Each has an ID that stays unique while the renderer is running, and one component on it must have the ID root.
Components as a flat list
Components are sent as a flat list that refers to children by ID, rather than as a nested tree. That suits streaming: the specification tells renderers to show placeholders for children or data that have not arrived yet, so the UI can appear piece by piece while the model is still generating.
A data model with bindings
Each surface has a data model. Component properties can hold a literal value, a binding to a path in the data model ({"@path": "/booking/date"}, using JSON Pointer), or a call to a named function (@call). When the user types into a bound field, the renderer updates the data model locally; when they tap a button, the renderer sends an action back to the agent.
Catalogs
A catalog is a JSON Schema document listing the components and functions an agent may use. The specification says defining your own catalog lets you "restrict the agent to using exactly the components and visual language that exist in your application." This is the main control point: if your catalog has no file upload component, the agent cannot ask for one.
The messages
From agent to renderer, the 1.0 specification defines createSurface, updateComponents, updateDataModel and deleteSurface, plus two messages for the new function calls, callRendererFunction and agentFunctionResponse. In the other direction the renderer sends user actions and its own function calls and responses (callAgentFunction, rendererFunctionResponse). Setting a data model value to null deletes that key. The media type is application/a2ui+json.
What changed in A2UI 1.0
Google's announcement lists the headline additions, and the project's 0.9 to 1.0 evolution guide covers the breaking changes.
| Change | What it means for you |
|---|---|
| Function calls in both directions | The agent can call functions the renderer exposes, and the renderer can call the agent's, with typed responses. Functions are named entries in the catalog, not code sent over the wire. |
| Accessibility support | An @accessibility key and live-region support, so screen readers can follow UI that changes while it streams. |
| Mixed catalogs | Components from more than one catalog can appear on one surface, for example your design system plus a charting catalog. |
| New agent SDKs | TypeScript and Dart join Python. Google also lists swappable inference formats and "A2UI Macros" in Python. |
| Renamed wire messages and @ keys | Envelopes are now agent-to-renderer and renderer-to-agent, and reserved keys start with @ (@path, @call, @index, @catalogId and others). The guide warns against migrating 0.9 payloads with a blanket find-and-replace. |
| Theme removed | The theme property and primaryColor are gone, to separate layout from branding. A 1.0 createSurface that still sends a theme fails strict validation. |
| One-message UI | Components and initial data can be sent inside createSurface, so a simple card needs a single message. |
Two cautions. First, renderer support is uneven at launch: Google says Jetpack Compose is on 0.9.1 with 1.0 "coming soon", Gemini supports 0.9.1 today, and ByteDance's Lynx renderer supports 0.9 and is adapting to 1.0. Check the version of every renderer you depend on before you target 1.0. Second, the 1.0 specification page shows a last-updated date of June 8, 2026, earlier than the November announcement, so read the evolution guide in the repository rather than assuming the spec page has every change.
A2UI vs AG-UI, A2A and MCP
These names get mixed up because they sit next to each other in an agent stack. They answer different questions.
| Name | Question it answers | Relation to A2UI |
|---|---|---|
| A2UI | What should the user see and be able to do? | The UI description itself. |
| AG-UI | How do agent events reach the user's app? | The A2UI specification calls it "the standard transport binding for Agent-to-User Interaction", one way to carry A2UI messages. |
| A2A | How do agents talk to other agents? | A2UI defines an A2A extension, so a remote agent can return UI. |
| MCP | How does a model reach tools and data? | A2UI messages can ride in MCP tool calls, tool outputs or resource subscriptions. See what MCP is. |
| MCP Apps | How does an MCP server show its own UI inside an assistant? | An MCP App can bundle an A2UI web renderer inside its ui:// HTML resource, which runs in a sandboxed iframe. |
The A2UI specification is transport-agnostic and also mentions WebSockets and SSE. We have described AG-UI only as A2UI's own documents describe it; read the AG-UI documentation for its full scope.
The practical difference between A2UI and MCP Apps is who draws the pixels. With MCP Apps, the server ships HTML that runs in an iframe inside the host. With A2UI, the agent ships a description and the host draws it with its own components, so it matches the host's look and works on native mobile as well as the web. Google says the two "work together", and its web and Flutter renderers run inside MCP Apps, which is how A2UI screens can appear in assistants that support MCP Apps today, such as Claude and Gemini.
The security model, and its limits
A2UI's design choice is to express UI as data. The project lists three guards: UI as data, input and output validated against a schema, and no arbitrary executable code. Functions in a catalog declare who may call them (renderer only, agent only, or either), and functions that need a user gesture, such as opening a URL, can only run on the renderer after the user acts. Google's post also says A2UI binds data and child components on the server "so sensitive values never reach the model."
That narrows what a manipulated agent can do, but it is not a full defense. A model that has read a poisoned web page or document can still fill an allowed form with misleading text, pre-select the wrong option, or label a button deceptively. So:
- Keep the catalog small. Register only the components a flow needs. Every extra component is something an injected prompt could use.
- Validate actions on the server. A button tap in A2UI is a request, not an approval. Re-check amounts, recipients and permissions where the action is executed. Our prompt injection guide explains why model output must be treated as untrusted.
- Show where content came from. For confirmations, render key values from your own data model, not from model-written labels. Our post on agent UX for trust covers confirmation patterns.
- Inside MCP Apps, keep the host's iframe sandbox and content security policy in place; the A2UI guide notes the iframe runs with scripts allowed but without same-origin access. See our MCP security checklist.
Who is using it
These are Google's claims, not ones we have checked. Google names Atlassian (bringing A2UI to Jira), Alation, Bloomberg and ByteDance as building with A2UI, says Gemini Enterprise is being upgraded to 1.0, and lists partner demo apps. The GitHub repository showed about 17,200 stars when we read it on November 12, 2026.
Should you use A2UI?
It is a good fit when:
- An agent in your product needs structured input or confirmation from a user (bookings, approvals, filters, multi-step forms), and plain chat makes that slow or error-prone.
- You ship on more than one platform and want the same agent to drive native UI on web, iOS and Android.
- You already have a design system and want agent output to stay inside it.
It is probably more than you need when the agent only ever returns text or a fixed set of screens your app already knows how to show. In that case, tool calls that return structured data, rendered by your own code, are simpler. Our comparison of function calling and MCP covers that pattern, and framework vs build your own covers the wider trade-off.
If you do adopt it, start with a one-surface flow, write your own catalog rather than shipping a broad one, pin the protocol version, and test with the renderer versions your users actually have.
How we approach this
This is our approach, not a rule. When we build agent features that need user input, we start with the smallest set of components the flow needs, keep the source of truth for any value the user confirms on the server, and log every action the UI sends back so it can be audited. A generative UI layer is worth adding once a flow has proved that chat alone is the bottleneck.
Sources: Google Developers Blog, A2UI 1.0 announcement (November 11, 2026), A2UI project site, A2UI v1.0 specification, A2UI concepts overview, A2UI in MCP Apps guide, A2UI 0.9 to 1.0 evolution guide, A2UI repository on GitHub. All read November 12, 2026.