Google's A2UI and CopilotKit Let Agents Build Interactive Interfaces

From text replies to rendered interfaces

The post opens with a travel example. A user asks for a holiday package to Bali in March, and the agent answers with six packages in prose, then points to the operator's site for booking. According to the authors, agents could plan the trip but had no standard way to render a selectable list, a map of destinations or a date picker inside the conversation.

Generative UI is described as the layer that lets agents build interfaces at runtime, shaped by what each request needs. Two pieces are required: a way to describe the UI, and an agentic stack that connects the agent to the application and renders the result.

A2UI (Agent-to-UI) is Google's framework-agnostic, transport-agnostic open standard for the first piece. The agent describes an interface as data, and the application draws it with components it already has. CopilotKit supplies the second piece. It integrates with agent frameworks such as LangChain, AWS Strands and Google ADK, and provides a chat surface, a runtime and an A2UI renderer across React and Angular. It also offers custom A2UI renderers for Vue and Slack.

How A2UI handles the spectrum of Generative UI

The post frames Generative UI as a spectrum. At the controlled end, developers build each component ahead of time and the agent picks which one to render and with what data. That is brand-safe, but it limits personalization. At the open end, the agent returns a raw UI program in HTML, JavaScript and/or Dart that runs in a sandboxed iframe. It covers anything unplanned, but the surface can drift from the design system and executes code written by a model.

A2UI works across that range, according to the post, though the declarative mode, where agents assemble pre-declared components and functions, is the most popular. The post lists several design points:

• Security first: A2UI is a declarative data format, not executable code. The client keeps a catalog of trusted components, so anything the agent invents outside that set is caught before it reaches the screen.
• LLM-friendly and streaming: The payload is a flat list of small JSON messages that reference each other by ID, so the agent emits it incrementally and the client renders components as they arrive.
• Framework-agnostic and portable: The same response renders through React, Lit, Angular, SwiftUI, Jetpack Compose or Flutter, plus community renderers for Vue and the terminal.

The Basic Catalog ships 18 general-purpose primitives across layout, display, input and containers. Because it is deliberately sparse, the post says most production apps define their own custom catalog, which can include anything the frontend already renders, such as a live map.

Setting up A2UI with CopilotKit

CopilotKit is built on AG-UI (Agent-User Interaction Protocol), which supports A2UI payloads and provides agent SDKs for many backends. The agent emits A2UI operations, AG-UI carries them to the client as typed events, and user actions travel back along the same stream. The post names Google ADK, LangChain, Mastra and Strands as AG-UI compatible, so setup is the same whichever one the agent uses.

Using Google ADK as the example, the ag_ui_adk package wraps an ADK agent and serves it as an AG-UI endpoint on FastAPI. On the app side, the endpoint is registered with the CopilotKit runtime at /api/copilotkit, which the post says needs nothing A2UI-specific. A2UI is switched on from the client: developers define what the agent may draw, map each definition to a renderer and pass the catalog to the CopilotKit provider.

In the example, a FlightCard definition has a description and a Zod schema. The description goes into the agent's prompt so the model knows when to use it, and the schema validates the props the model sends back. Configuration can be set up ahead of time on the server or created dynamically and shipped from the client with the request. Developers can also skip CopilotKit and consume the event stream directly with @ag-ui/client, passing operations to a compliant renderer such as @a2ui/react.

Bi-directional surfaces for multi-step flows

The post argues that most agent-generated UI is one-shot and goes stale when anything changes. A2UI surfaces are bi-directional and their components reactive, so actions such as picking dates, choosing a flight or entering passenger details travel back along the stream, and the agent re-emits the surface using those values.

Two things make the round trip work: inputs bound to a data path, and a button carrying an action that names which paths to send back. Validation runs on the client, so a bad email shows an inline error without a model call, and nothing reaches the agent until the button fires. The agent then re-emits against the same surfaceId, which lets flight search, results, passenger details and confirmation live on one surface. The post illustrates this with an AG-UI agent on Cloud Run streaming A2UI surfaces to a CopilotKit frontend.

What it means for developers

For frontend teams, the pitch in the post is to ship building blocks once and let the agent compose them for each request, with a trusted catalog acting as the boundary on what can appear on screen. Teams already using agent frameworks such as ADK or LangChain can, according to the post, add A2UI with a short client-side catalog definition rather than changing their backend approach.