An assistant can explain a complicated choice in a few paragraphs. Making that choice can still involve another five messages: change the date, remove an option, correct a number, then confirm the result. A small form would often do the job more clearly.
Google released A2UI 1.0 on November 11, 2026, to help developers build that kind of interaction. It is the first stable version of the project's open generative UI protocol. The agent describes an interface, and the application turns that description into controls the user can actually operate.
For teams building AI products, the interesting question is where an interface can remove unnecessary conversation. A2UI offers a way to build one without asking a model to invent an entire application every time.
What the agent sends, and what the app controls
A2UI separates the description of a screen from the code that draws it. The agent sends structured messages describing components and data. A renderer in the receiving app maps them to the app's UI framework.
The developer defines a component catalog: the controls, properties and functions the agent may use. An agent might choose from an approved set of cards, selectors and buttons, while the application retains control of how those components look and behave. The framework validates the output against that catalog rather than treating arbitrary generated code as a screen to execute.
That division is useful when a product already has a design system. A generated screen can use familiar controls instead of looking like a separate mini-site dropped into a conversation. It also gives the team a concrete place to decide which capabilities the agent should have.
What 1.0 changes
One of the main additions is bidirectional function calling. The agent and renderer can request functions from each other and return structured results or errors. A date selector could use that mechanism to request an updated availability check, provided the developer has implemented the function and allowed that caller to use it.
Version 1.0 also allows a single interface to combine components from multiple catalogs. Those catalogs must use the same A2UI specification version. Accessibility support has been extended, including attributes for live updates and hidden content, alongside clearer requirements for renderer implementations.
For an existing 0.9 application, migration deserves more attention than a package-version bump. The official evolution guide lists changes to message names, catalog definitions and reserved keys. It specifically warns against blindly replacing every occurrence of certain data keys. A migration should be checked against real payloads and user interactions.
Which platforms support it now?
The official SDK documentation lists 1.0 support for React, Angular, Lit, Flutter and SwiftUI. Agent SDKs are available for Python, TypeScript and Dart.
The remaining version boundaries matter. At the time of the announcement, Jetpack Compose supports 0.9.1, with 1.0 planned. ByteDance's Lynx renderer supports 0.9 and is being adapted. Google also says Gemini's current A2UI integration supports 0.9.1, while work on upgrading Gemini Enterprise is continuing.
A stable protocol therefore does not mean every renderer or host has already upgraded. Before choosing a stack, check the exact renderer, protocol version and host you intend to ship to. Support for the same framework name is not enough to establish compatibility.
How it fits with MCP Apps
A2UI can also run inside an MCP App. In that arrangement, the MCP App contains a web renderer, which turns A2UI messages into an interface within the host's isolated frame. User actions are passed back through the MCP Apps tool channel.
This is one route to showing an A2UI interface in a host that supports MCP Apps but does not render A2UI directly. The integration still has to respect the host's sandbox and content security policy. Developers should also check sample versions: the official guide distinguishes an older community sample from its newer implementation walkthrough.
Where it is worth trying
A practical first project would be a narrow interaction that already creates friction: editing a proposed schedule, comparing a few options or confirming the details of a request. Measure whether users finish with fewer corrections, whether controls remain understandable as data changes, and how well the screen recovers from a failed tool call.
The project's quickstart uses a travel-planning sample with a Python server and React and Flutter clients. It is explicitly a learning example, not a production-ready travel service. Real accounts, permissions, business APIs and transaction handling remain the application's responsibility.
The repository uses the Apache 2.0 license. That should not be confused with a promise that running an agent is free: model inference, hosting and external services have their own costs and conditions.
A2UI is worth watching because it makes the interface part of the agent's response. Whether that produces a better product depends on the interaction being designed and tested. This article is based on the official announcement and documentation reviewed on November 12, 2026; we have not run a hands-on implementation or performance test.