Google's A2UI 1.0 goes stable: agents describe screens as JSON, apps render them natively

Google's A2UI protocol hits 1.0

Google's A2UI, an open protocol that lets AI agents describe interfaces as structured JSON while applications render them with their own components, reached a stable 1.0 on November 11, 2026, according to a hands-on write-up on dev.to. Rather than stopping at the announcement, the author installed Google's React renderer, wired a genuine 1.0 payload into a Next.js app, exercised its buttons and worked through the specification end to end, producing one of the first practical accounts of agent-rendered screens in a mainstream web framework.

The problem the protocol targets is the shape of agent replies, not their accuracy. Per the dev.to analysis, chat-based interaction breaks down in three recurring situations: approvals, where a text "yes" leaves it unclear what was confirmed and at which values; comparisons and pickers, where inherently tabular information such as flights or time slots gets buried in prose; and forms, where collecting a handful of fields turns into a slow, error-prone sequence of round trips. What those cases share, the author observes, is a small, known-in-advance set of screens whose data changes every time — precisely the workload a component catalog suits.

Agents describe, apps draw

A2UI divides the work in two. The agent decides what a user needs to see and streams JSON messages that reference components from a catalog — cards, text lines, choice pickers, buttons — together with the data those components bind to. The application keeps full control of everything visual, implementing each named component natively within its own design system.

The agent sends neither HTML nor executable code, and it cannot reference a component the host has not registered. That gives the protocol a structural trust boundary: the most a bad payload can achieve is a poor arrangement of the app's own components. Styling stays with the app as well, since the wire format carries no theme at all — a 1.0 message that attempts to set one is invalid.

Four message types, one data model

According to the dev.to breakdown, an A2UI conversation is a stream of JSON objects resting on four structural messages. createSurface opens a named UI region and, in 1.0, may carry the entire component list plus the initial data model inline so a complete screen arrives in a single message. updateComponents adds or replaces component definitions, updateDataModel swaps data at a JSON Pointer path without resending the screen, and deleteSurface dismantles the region.

Components travel as a flat list rather than a nested tree: each has an id, a catalog name and properties, while containers point at children by id in what the spec calls an adjacency list, with one component required to carry the id root. The author highlights two payoffs from that shape — an agent can stream components in any order and patch one without resending the tree, and the strict separation of structure from data lets a live price feed, a user's typing and the agent itself all write to a single model that components read from.

The specification's basic catalog contains 18 components spanning layout (Row, Column, List, Card, Tabs, Divider, Modal), display (Text, Image, Icon, Video, AudioPlayer) and input (Button, CheckBox, TextField, DateTimeInput, ChoicePicker, Slider). A catalog is simply a schema document, and the write-up describes defining a custom catalog mapped to your own design system as the intended production path; the agent generates against whichever catalog appears in its prompt.

Actions flow back, and 1.0 adds function calls

User interactions return as action messages carrying the action's name plus a context object whose values are resolved from the data model at the moment of the press. Version 1.0 also introduces explicit function-call messages in both directions, including callAgentFunction, which lets the UI ask the agent to check something mid-interaction.

For a sense of scale, the write-up cites a fully composed deploy-approval surface at 3,131 bytes of JSON that renders across web, Android, iOS and MCP Apps hosts — versus roughly 118 lines of JSX handwritten for a single platform, before any state wiring, validation or action plumbing.

Why it matters

Because rendering is delegated to the host, one agent answer can display anywhere the catalog exists: web, Android, iOS, or assistants such as Claude and Gemini that host agent UI. For teams shipping agents, a stable 1.0 with a reference React renderer makes the protocol testable in a Next.js app today, and the security model needs no sandbox because nothing executable crosses the wire. The dev.to author also examines rough edges in the young protocol that an announcement alone would not surface. The open question is adoption: if hosts and frameworks converge on A2UI, the interaction patterns where chat fails worst — approvals, comparisons and forms — could move from prose to proper screens.