There’s a demo that gets shown at every Google agent talk this year. An agent receives a prompt — find restaurants near me — and instead of responding with a block of text, it streams back a fully rendered card UI. Complete with a list of restaurants, ratings, a map link, and a button to book. The audience oohs.
I wanted to see if that demo held up outside the demo.
It does. And it doesn’t.
What A2UI Actually Is
Let me be precise, because the framing gets muddled. A2UI (Agent to User Interface) is a protocol — a JSON schema with streaming semantics — that lets an AI agent describe a UI in structured messages that a client renderer can turn into real, interactive components.
The agent doesn’t write HTML. It doesn’t emit JavaScript. It sends something that looks roughly like:
{
"id": "root",
"type": "Card",
"children": [
{ "id": "title", "type": "Text", "text": "Sakura Ramen" },
{ "id": "rating", "type": "Text", "text": "4.7 ★" },
{ "id": "book_btn", "type": "Button", "label": "Book Table" }
]
}
That JSON streams to a client that already knows how to render a Card, Text, or Button. The client is your app. The renderer maps component types to your existing UI library — could be React, Angular, a Flutter app, something custom. The protocol is the contract between them.
This is genuinely useful. It’s also not magic.
The Component Catalog Problem
Here’s the part the demos skip over.
The agent can only render components that exist in the client’s registered catalog. In the restaurant finder demo, someone pre-built: Card, Text, Button, TextField, List, maybe a few others. The agent picks from that menu.
When you build your own app, you have to build and register those components first. You decide what your agent is allowed to show. You decide what a “good” Card looks like in your design system. You handle the onClick for the button. You manage the state.
So when the agent generates a UI, it’s really doing something more like: selecting the right pre-built component, populating it with data from a tool call, and streaming the description to the client. That’s powerful orchestration — and it’s not nothing — but the creative and engineering work of building the components is still entirely yours.
The agent is a brilliant orchestrator wearing borrowed clothes.
What Streaming Actually Looks Like
The one thing the demos get right is the streaming. That’s real and it’s the best part of the experience.
Instead of waiting for a complete response, you watch the UI assemble in real time. First a Card appears. Then the title text populates. Then the rating. Then the action button fades in. It feels alive in a way that a chat message never does.
This matters more than it sounds. A static response with five restaurant options forces the user to parse the options and decide in working memory. A streaming card sequence gives you one piece of information at a time, in the order the agent thinks is most persuasive. That’s a meaningful UX difference.
But — and this is a real but — it only works well when the agent’s streaming order is intentional. When it isn’t, you get weird sequences: the action button appearing before the title has loaded, or the agent switching component types mid-stream because it reconsidered its layout. The protocol handles the retries gracefully, but the user sees a UI that visibly fidgets.
The Hardest Part Isn’t Technical
After running the restaurant finder and building a second agent of my own, I’m convinced the hardest part of A2UI has nothing to do with the protocol.
It’s the product decision of what the agent should show.
When should the agent use a Card versus a List? When does it make sense to render a form versus inline text inputs? A table for three columns or a stack of cards? The agent will do something by default if you don’t give it clear guidance — but the default is usually “safe and generic,” which means a mediocre experience.
You end up writing what amounts to UI prompting: instructions for the agent about when to reach for which component, what data to surface first, when to group versus scatter. This isn’t documented well anywhere. It’s the kind of tribal knowledge that lives in a senior engineer’s head.
Where It Genuinely Shines
The restaurant use case is actually perfect for A2UI. You have structured data (name, rating, cuisine, distance), a clear action the user might take, and a relatively fixed set of states (loading, results, empty, error). The agent’s job is mostly “pick the right component, populate it with the right data, stream it in a sensible order.”
It’s also genuinely cross-platform. The same agent JSON renders on a web client and a Flutter mobile client, because both are just renderers over the same protocol. That’s not hypothetical — the spec was designed for exactly this. The moment you need your agent’s UI to appear on iOS and web without writing platform-specific code, A2UI starts looking very attractive.
The V1.0 Question
As of June 2026, v0.9.1 is the stable release and v1.0 is in release candidate. The migration path from v0.9 is the big reason to watch the 1.0 rollout — there’s a certification program coming that will matter for enterprise adoption.
The more interesting question is whether the component catalog story gets solved. Right now, every team using A2UI is essentially building their own component library from scratch. There are adapter bridges (Mantine, ShadCN) that cover the 75+ most common components, but the design system integration work is still on you.
Google’s I/O announcement this year stitched MCP, A2A, and AG-UI together into a full agent stack — and A2UI is the presentation layer of that stack. The vision is coherent: agents that can talk to each other (A2A), use tools (MCP), and render UIs (A2UI) without any proprietary lock-in. That’s a compelling vision. The gap between that vision and a production app is still wide, and it’s mostly made of component catalog work.
The Bottom Line
A2UI solves a real problem: it gives you a safe, declarative way to let an agent drive a UI without executing arbitrary code. The agent can’t escape its component catalog, so the attack surface is bounded. The streaming UX is genuinely better than text. The cross-platform story is real.
What it doesn’t solve: the “what should the agent actually show” problem. That requires product judgment, component engineering, and UI prompting that no protocol can automate.
The demos show you the payoff. They don’t show you the catalog.
A2UI is an open project maintained at a2ui.org. The v1.0 release candidate is available now.