A2UI 1.0 Is Here: AI Agents Can Finally Answer With a Screen, Not a Wall of Text

Google just released A2UI 1.0, a stable, open protocol that lets AI agents reply to users with interactive screens, such as a form, a chart, or a combined view pulling data from several apps, instead of a paragraph of text. It ships with open-source renderer libraries for the web, Android, and iOS, and agent SDKs in Python, TypeScript, and Dart.

That matters right now because the gap between what AI agents can do and what they show has become embarrassing. Agents can orchestrate six apps at once, yet they hand the result back as a numbered list. A2UI is the first serious attempt to close that gap at the protocol level, and version 1.0 means the API is stable enough to build on in production.

The core idea, translated for designers

A2UI works like this: the agent decides what to show, describes it using the A2UI protocol, and then the app draws it using its own native components and your own design system. The LLM never touches your raw data or generates raw HTML. It composes a view from components you have already registered, so sensitive values stay on the server and the UI renders at native speed.

For designers, that distinction is huge. It means an agent interface built with A2UI does not look like a generic chatbot bolted onto your product. It looks like your product, because it is your components, your spacing, your brand. Atlassian is already doing this in Jira: when an AI agent needs a decision from the team, it surfaces an interactive card inside the work item, right where the team already lives, rather than dumping instructions into chat.

What actually shipped in 1.0

A few specifics worth knowing:

A2UI Express and decision models. There are two ways an agent can generate UI: a "slow" path where an LLM composes the view by writing a description, and a faster "system one" path where a lighter decision model just picks which components to show. The fast path reduces latency noticeably in production, which matters a lot in conversational interfaces where every extra second feels like a freeze.

Bidirectional function calls. A flight picker can check seat availability live, mid-interaction, without the user leaving the view or the agent losing context. This is new in 1.0 and it makes reservation-style flows actually usable.

MCP Apps support. The web and Flutter renderers work inside apps that support MCP Apps, a standard for connecting AI assistants to external tools. That means an A2UI screen you build can appear inside Claude or Gemini, not just in your own app. Build it once, and it shows up wherever your users already are.

A2UI Playground. If you want to try it without setting anything up, CopilotKit has built a sandbox at go.copilotkit.ai/a2ui-playground where you can experiment with A2UI components directly in the browser.

How a designer-builder could actually use this

If you are building vibe-coded projects with AI and you have ever wrestled with how to make an AI response feel like a real product moment rather than a chatbot reply, A2UI is worth your attention.

The practical starting point is the Playground. You can register a component, describe a scenario, and see how the agent composes a view before writing a single line of agent logic. That is a feedback loop designers are comfortable with: show, adjust, iterate.

From there, the realistic path is to pick one narrow flow in your app where a text reply genuinely fails. The article uses a great example: asking an agent to reschedule dinner with a friend. A text reply gives you a list of questions. An A2UI reply gives you one view with your calendar, available restaurant slots, and rideshare prices lined up side by side. That is a design decision as much as an engineering one, and A2UI gives you the vocabulary to spec it.

You will still need a developer, or some comfort with TypeScript or Python SDKs, to wire up the agent side. A2UI is a protocol, not a no-code tool. But the component-registration model means a designer can define the building blocks, and the agent figures out how to assemble them. That division of labour is actually pretty close to how design systems work already.

What to watch and what to hold back on

Atlassian, Alation, Bloomberg, and ByteDance are listed as early adopters, which suggests the protocol has been pressure-tested in real products. That is a reasonable confidence signal for a 1.0.

The Android renderer (Jetpack Compose) is currently at v0.9.1 with 1.0 coming soon, so if Android coverage is critical for your project, check the status before committing.

The bigger open question is ecosystem momentum. A2UI needs AI assistants, app developers, and design system teams to all adopt the same protocol for the "build once, render anywhere" promise to pay off fully. That coordination is hard, and it is too early to know whether A2UI becomes the standard or one of several competing approaches.

For now, the most grounded takeaway is this: if your project involves an AI agent that answers questions, A2UI 1.0 gives you a real, stable option for making those answers feel like designed experiences rather than typed output. That is not nothing. That is actually the thing most AI products are missing.