A2UI: Google's Protocol for Agent-Driven User Interfaces

The way AI agents interact with users is undergoing a fundamental shift. For the first two years of the generative AI wave, agents mostly operated in text: a chat box in, a text response out. Richer experiences required the application developer to hand-craft the UI, figure out how to stream agent output, and write custom glue code for every new agent or framework. Google's A2UI protocol changes that story entirely.

A2UI (Agent to UI) is an open, declarative protocol—licensed under Apache 2.0 and hosted at a2ui.org—that lets AI agents describe rich, interactive interfaces in a structured JSON format. Clients parse that JSON and render using native components: React for the web, Flutter for mobile, Angular for enterprise apps, or whatever framework the host application already uses. The agent never executes code in the client; it only describes what should be shown. Security, accessibility, and native feel come for free.

With 14,000+ GitHub stars and active contributions from both Google and the broader open-source community (including CopilotKit), A2UI is quickly becoming the standard way agents ship their own interfaces.

Why Generative UI Needs a Protocol

Before A2UI, the options for rendering agent-generated UIs were essentially:

1. Free-form markdown/HTML. Simple, but agents produce wildly inconsistent markup, accessibility is an afterthought, and every client has to build its own sanitization and rendering pipeline.
2. Custom JSON schemas per product. Teams like Vercel's AI SDK pioneered the idea of structured components, but each implementation was bespoke. Migrating to a new agent framework meant rewriting the rendering layer.
3. Code execution (tool calls that run JS in the browser). Powerful but dangerous—you're trusting the model to produce safe, correct code at runtime.
4. Static tool-call responses rendered by the developer. Gives great control, but the agent can't adapt the UI dynamically; it can only pick from a fixed set of pre-built components.

A2UI solves all four problems with a single clean abstraction: a declarative, streaming JSON payload that describes UI trees, data bindings, and user interaction events. Agents produce it; clients consume it.

Core Architecture

Surfaces and Components

An A2UI surface is the top-level rendering target: a panel, a modal, a sidebar, a full-page view. Within a surface, the agent describes a tree of components—things like Button, DataTable, Card, Chart, Form, Text, Image. The component catalog is curated and approved by the host application, so agents can only use components that have been explicitly whitelisted. This is the primary security boundary.

{
  "type": "surface",
  "id": "dashboard",
  "title": "Sales Summary",
  "components": [
    {
      "type": "Text",
      "id": "header",
      "props": { "variant": "h2", "content": "Q2 2026 Performance" }
    },
    {
      "type": "DataTable",
      "id": "sales-table",
      "props": {
        "columns": ["Region", "Revenue", "Growth"],
        "rows": [
          ["North America", "$4.2M", "+18%"],
          ["Europe", "$2.8M", "+12%"],
          ["APAC", "$1.9M", "+31%"]
        ]
      }
    }
  ]
}

Each component maps to a real, natively rendered UI element. The React client renders a DataTable using whatever table component the host app already uses—MUI, shadcn/ui, Ant Design, or a custom design system. There are no iframes, no shadow DOMs, no style isolation hacks. The rendered UI inherits the app's theme, spacing, and accessibility tree automatically.

The Adjacency List Model

Traditional hierarchical component trees are hard for LLMs to generate incrementally. A deeply nested JSON tree requires the model to "know" the full structure before closing every parent node. A2UI solves this with an adjacency list model: every component is a flat entry in a list, and parent-child relationships are expressed through explicit parent and children id arrays—exactly like how modern rendering engines represent virtual DOM trees internally.

{
  "nodes": [
    { "id": "root", "type": "Column", "children": ["card-1", "card-2"] },
    { "id": "card-1", "type": "Card", "parent": "root", "props": { "title": "Revenue" } },
    { "id": "card-2", "type": "Card", "parent": "root", "props": { "title": "Churn" } }
  ]
}

This flat structure means the model can emit nodes one at a time as it generates them, and the client can start rendering immediately. The UI literally builds itself in front of the user as the agent thinks through it—no waiting for the full response.

Data Binding

Components can bind to named data slots rather than hardcoding values. This enables the agent to emit a component structure once and then stream updates to just the data:

{
  "id": "metric-card",
  "type": "MetricCard",
  "props": {
    "label": "Active Users",
    "value": { "$bind": "metrics.activeUsers" }
  }
}

When metrics.activeUsers updates in the data layer, the card re-renders without re-emitting the entire component tree. This is especially useful for live data dashboards and real-time analytics agents.

What's New in v0.9

The v0.9 draft (published November 2025, last updated December 2025) added four major capabilities:

1. createSurface

Previous versions required host applications to pre-register surfaces. v0.9 lets agents dynamically create new surfaces at runtime:

{
  "action": "createSurface",
  "id": "analysis-panel",
  "placement": "right-panel",
  "title": "AI Analysis"
}

This gives agents much more autonomy—they can open new panels, modals, or sidebars as needed without the host developer having predicted every possible surface in advance.