Gemini Can Now Build Your UI on the Fly. Here Is What That Actually Means for Designers.

Google just released A2UI, an open standard for letting AI agents generate interactive UI components at runtime, inside the conversation itself. Paired with CopilotKit's agent integration layer, it means your AI can now hand a user a date picker, a sortable list, or a live map, not just a paragraph describing one.

That is a meaningful shift. And if you are building vibe-coded projects with AI tools, it is worth understanding what just became possible.

Why "walls of text" is an actual design problem

Think about every AI assistant you have used. You ask for five hotel options. You get five paragraphs. You have to read, mentally compare, click away, come back. The agent did the hard work but then dumped the result on you in the least usable format possible.

This is not a writing problem. It is an architecture problem. Until now, agents had no standard way to say "render a selectable card here" or "drop a map here with these coordinates." Everything came back as prose because prose was the only shared language between the agent and the screen.

A2UI is the shared language that was missing.

What A2UI actually is

A2UI (Agent-to-UI) is Google's open standard for generative UI. Instead of an agent returning text, it returns a structured data description of an interface. Your app reads that description and draws it using components you already built and control.

A few things make this design-friendlier than it sounds:

It is declarative, not executable. The agent does not write code that runs in your app. It describes what it wants, using a catalog of components you pre-approved. Anything outside that catalog is blocked before it reaches the screen. Your design system stays intact.

It streams. The payload arrives as a flat list of small JSON messages, so components appear as the agent generates them, rather than all at once after a long wait.

It is framework-agnostic. The same A2UI response can render in React, Angular, SwiftUI, Flutter, or even Vue via community renderers. Write your components once; they work across surfaces.

A starter set called the Basic Catalog ships with 18 general-purpose primitives covering layout, display, input, and containers. Most production apps will define a custom catalog on top of that, mapping their own existing components into the set the agent can use.

Where CopilotKit comes in

CopilotKit handles the plumbing between your agent and your app. It is built on AG-UI, a protocol for agent-to-user interaction, which carries A2UI payloads as typed events and sends user actions back the same way.

The practical upside: A2UI works with any AG-UI-compatible agent framework. Google ADK, LangChain, Mastra, and Strands all qualify, so you are not locked into one backend choice.

Setup breaks into two halves. On the agent side, you wrap your agent with a package that serves it as an AG-UI endpoint. On the client side, you define a component catalog, meaning you list which components the agent is allowed to render and what props each one accepts, then pass that catalog to the CopilotKit provider. The description you write for each component is what the language model reads when deciding which component to use and how to fill it. Clear descriptions produce better, more reliable UI choices.

What this changes for a designer who is building

If you have been assembling AI-powered apps and hitting the ceiling where the agent response is always just text in a chat window, A2UI is the answer to that ceiling.

The practical opportunity is this: you design your components once, describe them clearly, and let the agent decide which ones to compose for each request. A search for "flights to Tokyo in April" could render actual flight cards. A recipe request could render ingredient checkboxes. A budget query could render a sortable breakdown. The agent picks the right pieces from your approved set and assembles them live.

For designers, the interesting creative constraint here is the catalog itself. What you register is what the agent can use. That means your design decisions happen up front, not at request time. You are essentially curating a kit of parts, and the agent improvises within it. That is a genuinely new design brief.

What to watch for

A2UI is open and young. The Basic Catalog of 18 primitives is deliberately minimal; Google expects most apps to build their own. That means there is real work involved in defining a useful catalog, testing how well the model interprets your component descriptions, and handling edge cases where the agent picks the wrong component or fills props with bad data.

The open-ended mode, where the agent can generate raw HTML or JavaScript in a sandboxed iframe, also exists for situations your catalog does not cover. It is more flexible but it steps outside your design system, so it warrants caution.

The technology is solid in its architecture, but the design craft of writing good component descriptions, curating the right catalog, and deciding where generative UI helps versus overwhelms the user is still very much an open question. That is, honestly, where designers have something real to contribute right now.

The walls-of-text era is ending. The era of deciding exactly what your agent is allowed to build is just starting.