This is a submission for the Google Cloud NEXT Writing Challenge
Everyone came out of Google Cloud NEXT '26 talking about the same things.
The Gemini Enterprise Agent Platform. The 8th-generation TPUs. The Apple partnership. The $32 billion Wiz acquisition is baked into their security stack. All legitimate, all impressive, all getting the clicks they deserve.
But buried 35 minutes deep inside the Developer Keynote — sandwiched between a Las Vegas marathon simulation and a joke about running being awful — was a two-minute demo of something called 'A2UI' that I haven't seen a single think piece about.
That's a mistake. Because A2UI is the announcement that will actually change what it means to be a frontend developer.
What Even Is A2UI?
Here's the demo setup from the keynote: the marathon planning system had an evaluator agent that scored proposed race routes. The problem was, how do you show those evaluation results to a user without hardcoding a dashboard?
The answer the team gave was A2UI. The agent didn't return the text. It didn't run code. It returned a declarative JSON description of a UI — cards, maps, scores, and components — and the frontend rendered it natively using its own existing widgets. The agent designed the interface. The frontend just executed it.
That's the shift. And it sounds subtle until you sit with it.
A2UI (Agent-to-User Interface) is an open standard — Apache 2.0, on GitHub, with contributions from Google and CopilotKit — that lets AI agents "speak UI". Instead of responding with a wall of text, an agent sends a structured JSON payload describing what the interface should look like. The client application maintains a trusted catalogue of pre-approved components (a Card, a Button, a DatePicker, a ``), and the agent can only compose from that catalogue. It cannot inject code. It cannot execute anything arbitrary. It declares intent, and the frontend renders it using its own native widgets.
The result: one agent response that renders natively across Angular, Flutter, React, and mobile — without a single extra line of UI code.
Why This Is Bigger Than It Looks
Let me frame the problem A2UI is actually solving, because the keynote moved too fast to do it justice.
Right now, when you build an AI agent, you face a brutal choice. Either you give it a fixed UI — hardcode the dashboard, predecide every screen, ship a design system and pray the agent's outputs fit the layout you chose — or you let it generate code on the fly, which is a security nightmare and a maintenance hell you don't want to have.
Neither option is good. Fixed UIs make your agent feel dumb ("why can't it just show me a chart?"). Generated code makes your security team quit.
A2UI is the third option nobody realised they were waiting for: declarative, sandboxed, generative UI.
The agent says: "I want to show the user a card with a map, two metric tiles, and a confirm button." The client says, "I have those components. Here they are, styled to my design system, following my security policies."* The user sees a beautiful, contextually appropriate interface that didn't exist in code five seconds ago.
What makes this genuinely new — and genuinely safe — is that the agent cannot reach outside the catalogue. There's no UI injection vector. There's no arbitrary code execution. The trust boundary is clean. The developer stays in control of what components exist. The agent only gets to compose.
The Keynote Demo Undersold It
In the marathon simulation demo, the presenters used A2UI to render a route evaluation card. Nice. Functional. Easy to gloss over.
But watch what happens when you extend that idea:
Imagine a customer support agent. A user files a complaint. Instead of the agent dumping a paragraph of text, it generates a structured claim form — pre-filled with the details it already knows, with a date picker for the incident, a dropdown for severity, and a submit button wired to your existing backend. The agent composed that form. Your design system rendered it. The user never typed more than they had to.
Imagine a developer tools agent. A user asks, "What's wrong with my deployment?" Instead of a wall of logs, the agent returns a tabbed interface: one tab for errors, one for warnings, and one for a recommended fix with a one-click apply button. The agent decided that three tabs were the right answer to this question. Tomorrow it might decide a timeline view is better. You didn't write either layout.
This is what the keynote called moving "beyond walls and walls of text". That's underselling it. What A2UI actually moves us beyond is the assumption that the UI is a static thing that developers design in advance and agents fill in. The interface itself becomes a runtime decision. The agent decides what shape the information should take.
Where It Stands Right Now
A2UI is currently at v0.9 (Public Preview), just updated two weeks ago. It's functional, it's on GitHub, and it already supports Angular, Flutter, Lit, and React renderers. The v0.9 release added a shared web-core library, an official React renderer, client-defined functions for validation, and a new Agent SDK that handles streaming, version negotiation, and incremental parsing — so the UI builds in real-time as the agent generates it, rather than waiting for a full JSON block to arrive.
It's not 1.0 yet. The spec is still evolving. Some renderer integrations are more mature than others. But the core idea is stable, the open-source community is active (CopilotKit has already shipped an A2UI starter template and composer tool), and Google is clearly building it into the broader ADK/A2A/Gemini stack as a first-class citizen.
The trajectory is obvious: every agent that ships on Google's platform will eventually be able to speak A2UI. Every frontend that integrates the renderer gets dynamic, agent-composed interfaces for free.
What This Means for Frontend Developers
I want to be precise here, because I'm not making a doom-and-gloom argument.
A2UI doesn't make frontend developers obsolete. It changes what they build.
Instead of building screens, you'll build component catalogues — the vocabulary the agent is allowed to speak. Instead of designing flows, you'll define the grammar. Instead of wiring up every state transition, you'll write the rendering logic once and let the agent decide when and how to assemble it.
That's actually a more interesting job. You're no longer implementing a specific user journey. You're building a system that can express any user journey the agent determines is appropriate.
But it does mean the instinct to hardcode — to say "this agent always shows a table, this one always shows a form" — will increasingly be the wrong instinct. The instinct you want is "What components does this agent need access to, and what should it never be able to render?"
Frontend developers who think in those terms will be indispensable in the agentic era. Those who keep thinking in terms of fixed layouts will find themselves constantly rebuilding UIs to accommodate agent outputs that don't fit the box they designed.
The Underrated Bet
Google announced a lot at NEXT '26. The TPUs are extraordinary. The agent platform is genuinely ambitious. The Apple partnership is a strategic earthquake.
But A2UI is the announcement with the longest tail.
Every other announcement requires infrastructure, budget, and migration planning. A2UI is a protocol. It's open source. It runs today on the frameworks developers already use. It's the kind of thing that quietly becomes load-bearing in the ecosystem before anyone agrees it's important.
It got two minutes on stage at the developer keynote. It deserved twenty.
If you build agents, go read the A2UI spec. If you build frontends that agents talk to, go integrate the renderer. If you're designing the next generation of AI-powered products, go think hard about what a component catalogue means for your design system.
The marathon demo was fun. But A2UI is what I'll still be thinking about in six months.
Top comments (0)