A2UI 1.0 Explained: Google's Generative UI Protocol for Agents, What Changed, and When to Use It

A2UI is an open protocol that lets an AI agent answer with an interactive screen, such as a form to confirm, a chart or an approval card, instead of a wall of text. The agent describes the screen as data, using only components your app has registered, and your app draws it with its own native components. Version 1.0, released by Google on 11 November 2026, is the first stable release. It adds two-way function calls and mixing components from several catalogs, and ships agent SDKs for Python, TypeScript and Dart. Use it when an agent needs to collect a decision or show structured data across web and mobile, especially when the agent sits outside your trust boundary.

The problem it solves

Agents answer in text because text is what models produce. That works for a question and fails for a task. Comparing three products, approving a plan with ten steps or picking a time that works for four calendars turns into round after round of "which one?". The obvious fix, letting the model write HTML or React, creates a worse problem: arbitrary model-generated code running in your product, styled however the model likes, with whatever behavior it invents.

A2UI takes the middle path. The app publishes a catalog: the components the agent may use, their properties and the functions it may call. The agent composes a screen from that catalog as structured data. The app validates it and renders it natively. The agent controls layout and wiring; the app controls what exists and what it does.

How it works

A2UI has three layers:

1. Inference. A model writes a description of the UI in an inference format. The default for new work is A2UI Express, a compact constructor-call notation such as root = Text("Hello"). Direct JSON still works. A decision model can also pick components from a list instead of writing text.
2. Transport. An agent SDK parses the model's output, validates it against the catalog, expands macros and emits wire messages: createSurface, updateComponents, updateDataModel and deleteSurface, sent as application/a2ui+json over whatever channel you use, including A2A, AG-UI or MCP.
3. Rendering. In the app, a core library turns messages into a framework-neutral UI tree, a framework adapter maps it to native widgets, and the catalog limits what can appear.

Here is what the model actually writes. This Express block and the JSON it compiles to come from the project's own conformance tests:

root = Column([greeting, farewell])
greeting = Text("Hello")
farewell = Text("Goodbye")

{
  "version": "1.0",
  "createSurface": {
    "surfaceId": "default_surface",
    "catalogId": "conformance/simplified",
    "components": [
      { "id": "root", "component": "Column", "children": ["greeting", "farewell"] },
      { "id": "greeting", "component": "Text", "text": "Hello" },
      { "id": "farewell", "component": "Text", "text": "Goodbye" }
    ]
  }
}

Variable names become component IDs, and the SDK, not the model, writes the envelope. If the model names a component the catalog does not declare, compilation fails with a validation error before anything reaches the screen.

Values reach the screen through a data model. A component binds to a path such as /booking/time, and the agent server fills that path from your systems. The model can lay out a balance field without ever seeing the balance. User actions and permitted function calls flow back to the agent as events.

What changed in 1.0

The evolution guide from 0.9 to 1.0 is long. The changes that matter for most teams:

Renderers ship for React, Angular and Lit on the web, Flutter, and SwiftUI. The Jetpack Compose renderer is on 0.9.1 with 1.0 support announced as coming soon, and Gemini renders 0.9.1 today, so expect mixed versions in the field for a while.

The token claim, read properly

The launch posts say Express describes the same UI in about three times fewer output tokens than JSON. The project's benchmark (54 samples, gemini-3.8-flash, temperature 0) supports that for the UI code itself and adds detail the headline leaves out:

Two readings. With thinking on, most output is reasoning, which Express does not shrink, so the saving on total output is about a quarter rather than two thirds. And the 45% input saving is the quieter win: compact component signatures replace full JSON Schemas in the system prompt, and that prompt is paid on every turn. As a rough independent check, the four multi-component cases in the project's Express conformance suite compile to minified JSON about 3.1 times larger in bytes (range 2.4 to 3.8). Bytes are not tokens, and four small cases are not a benchmark, but the direction agrees.

Who is using it

Google's launch post names four outside adopters. Atlassian is bringing A2UI to Jira, where an agent working a ticket asks the team for a missing decision through an interactive card in the work item. Alation renders metric cards and charts with it, the same feed inside its product and inside Claude through MCP Apps. ByteDance shipped an A2UI renderer for its Lynx framework in June 2026. Bloomberg is building with it. Inside Google, Gemini Notebook asks deck-format questions through A2UI cards, and Gemini Enterprise agents can already respond with A2UI.

One detail connects to work we have covered: ByteDance's Lynx playground uses a decision model, Jev, to pick components and values instead of having an LLM write text, and official SDK support for decision models is on the A2UI roadmap. Picking from a fixed catalog is a classification problem, which is where System One decision models are fast and calibrated.

A2UI, AG-UI, MCP Apps and A2A

These names arrive together, and they answer different questions:

They compose. A2UI messages can ride inside AG-UI events or A2A messages, and A2UI screens can render inside an MCP App, which is how Alation's feeds appear in Claude.

When to use it, and when not

Use it when:

• The agent needs a decision or structured input: approvals, forms, pickers, comparisons.
• The same agent serves web and mobile, and you want one description rendered natively on each.
• The agent is remote, third-party or across a trust boundary, and you need to limit what it can put on screen.
• Sensitive values should stay out of the model's context.

Skip it when:

• The answer is plain text, or a single static chart you could render from a tool result.
• You control both agent and front end, and your UI needs are a handful of fixed cards; plain typed tool results may be simpler.
• You need arbitrary custom logic inside components. Sandboxed logic is a roadmap item, not 1.0.

The forward deployed angle

Generative UI is turning up in agent design rounds as "the agent should not just answer, it should get the user to approve something". The strong answer separates three decisions: what the model may decide (layout and wiring, from a catalog), what the app enforces (validation, allowed calls, user activation for anything with side effects), and where data comes from (bound paths filled by your systems, not values the model typed). That separation is the same instinct behind guardrails on tool calls, applied to the screen. Practice it on RAG and agent design questions, and be ready to say why you would not let a model emit HTML into a customer's product.

Facts as of 12 November 2026: A2UI protocol 1.0, launch post of 11 November 2026, inference-format benchmark from the project documentation. See a2ui.org and the repository for current versions.