Google makes A2UI 1.0 stable for native agent interfaces Google makes A2UI 1.0 stable for native agent interfaces

The model describes; the app draws

A2UI sends an interface description as structured data. The application maps that description onto components it already knows, rather than executing arbitrary model-written interface code. Its repository describes three separate stages: model inference, validated transport messages and rendering. A core library holds the interface and data representation; a framework adapter turns that representation into native widgets. The component catalog determines which widgets are available. That division gives product teams a specific boundary to control: a model can assemble approved controls without owning the implementation of those controls. The project supports language models and decision models as producers of the interface description.

Calls can travel in both directions

The 1.0 evolution guide adds explicit messages for an agent calling a renderer function and for a renderer calling an agent function. Each direction has a corresponding response carrying a result or error. Catalog definitions identify permitted callers, which the runtime checks before execution. Multiple component catalogs can now contribute to one surface, provided they use the same protocol version. A component can identify its own catalog or inherit the surface default. If neither exists, resolution fails instead of silently selecting a catalog advertised elsewhere. These rules make the source of a control part of the interface contract.

A stable protocol is not a simultaneous rollout

Google lists web renderers for React, Angular and Lit, alongside Flutter and SwiftUI options. Its launch announcement separately places Jetpack Compose and Gemini Enterprise on 0.9.1, with upgrades to 1.0 still ahead. That distinction matters for a product shipping the same workflow across devices. The protocol can be stable while a particular host still needs an older message format. Google also describes A2UI cards in Jira and Gemini Notebook. Those examples concern interfaces that gather missing details or confirm choices, bringing structured interaction into an agent conversation.

MCP Apps provide another container

A2UI can also run inside an MCP App, rather than requiring the host assistant to install an A2UI renderer directly. The integration guide describes a self-contained HTML bundle with its own renderer inside a sandboxed frame. A button press travels through the host to an MCP tool, and the result updates the interface data. This separates the interface protocol from its delivery container. The guide also distinguishes model-visible launch tools from app-visible interaction tools. Its sample still uses older 0.8 messages, while the walkthrough explains newer payloads. The same guide notes that the sandbox blocks ordinary browser storage, so durable state belongs on the server.