Google’s A2UI 1.0 brings interactive forms to AI replies

Google released the first stable version of A2UI on November 11, giving developers an open protocol for AI replies that include working forms and buttons. In an app built with A2UI 1.0, someone could choose a date in a reservation form and see what is available without sending another chat message. The app draws the controls itself from the description the agent sends.

Google points developers to implementations for the web, Flutter and SwiftUI on iOS. Flutter can also render the screens in Android apps. Google says its separate Jetpack Compose renderer and the Gemini component gallery for registered agents currently support version 0.9.1.

The app draws the controls

The agent sends structured data describing which controls to show and what values they should contain. The app assembles the view from the components its developer registered, such as a button, a choice list or a text field. An order form could stack size and color choices on a phone and put them side by side on a wider screen. How those choices look and behave depends on the implementation in each app.

Earlier versions already let an app tell the agent when a user clicked a button or acted on a form. Version 1.0 adds a way for the two sides to call specific functions and receive a result or an error in reply. An agent can request the dimensions of the device’s screen from the app. The app can ask the agent to run a discrete check, such as looking up stock.

A lookup can happen inside the form

Consider a reservation form that checks open times when a customer picks a date. The app can send the date to the function that looks up availability and display the result in the same form. A developer can use the exchange to update a part of the screen without a new conversational turn. The service still defines what happens when a customer commits to the booking.

Developers specify which functions the app can invoke, which the agent can invoke and which require an action by the user. For example, the app can require a person to press a button before it opens a link. The code drawing the interface checks those rules before acting on the request and returns an error when the request is outside the permitted scope.

Labels for assistive technology

The 1.0 specification gives accessibility information its own reserved field, keeping it distinct from an app’s custom properties. That field can carry a component’s name and description. A screen reader can use the information to distinguish controls that look alike. The protocol can also describe how to announce a change. The Flutter implementation’s changelog says it updates the information it exposes to assistive technology when those values change.

One example in Google’s announcement comes from Gemini Notebook. Before making a slide deck, it asks what kind of slides the user wants and which topics to cover. A second card lets the user edit the format, focus and visual style before generation. Google first announced this slide workflow on October 19. It cited it in the November release as an example of A2UI in use.

Google also showed an example from Jira. When an agent needs a missing detail or a decision, it puts a question in the work item, where the person who assigned the work can answer. Atlassian’s support documentation says a site administrator must enable the relevant AI features and that assigning agents to work uses the organization’s Rovo credits. Separately, Atlassian asked developers on November 10 for feedback on an early-access plan to let them build A2UI components for Rovo Chat.

The web and Flutter renderers can also run inside MCP Apps, which let a compatible AI assistant display a tool’s interface. Which version a screen can use depends on where the developer chooses to render it. Google says it is working on upgrading Gemini Enterprise to 1.0. Its administrator documentation, updated November 10, lists 0.9 and 0.8 as supported. Google’s release announcement gives no date for the upgrade.