Skip to content

A2UI: Framework-Agnostic Generative UI Standard

A2UI is an open standard for agents to emit declarative UI blueprints that a host application renders with its own native components — the wire format for the agent → UI handoff.

What A2UI Is

A2UI is an Apache 2.0 spec from Google for describing UI as structured data. An agent emits JSON referencing components from a catalog the host advertises; the host renders them with its native widgets. Google released v0.8 in December 2025 and shipped v0.9 on April 17, 2026 with renderers for Flutter, Lit, Angular, and React plus a Python Agent SDK.

It sits alongside the other agent-facing open standards: llms.txt, AGENTS.md, Agent Skills, MCP, and A2A. A2UI covers the agent-to-UI handoff.

The Mechanism

A2UI moves the trust boundary from UI to data. The agent emits a JSON blueprint — "a flat list of components with ID references" — against a client-declared "Trusted Catalog" (Google Developers Blog). It never emits HTML, JS, or component code.

graph LR
    A[Agent] -->|JSON blueprint| B[Transport]
    B -->|A2A / MCP / AG-UI / WS / REST| C[Host App]
    C -->|catalog lookup| D[Native Widgets]
    D --> E[Rendered UI]

The host keeps control over styling and security: the blueprint references only pre-approved components and cannot embed code. This mirrors MCP's tool model — structured schema in and out, execution belongs to the host.

The alternatives have known problems. Sandboxed HTML/JS in an iframe "is heavy, can be visually disjointed (it rarely matches your app's native styling), and introduces complexity around security boundaries" (Google Developers Blog) — the model MCP Apps uses. Direct DOM manipulation works locally but breaks remotely.

What v0.9 Shipped

The v0.9 release consolidates the spec and adds production features:

  • Python Agent SDKpip install a2ui-agent-sdk — wraps schema management, catalog loading, and incremental JSON healing for streaming.
  • Shared web-core library across the React, Lit, and Angular renderers.
  • Client-defined functions — host-side validation and callbacks the agent can reference.
  • Client-to-server data syncing for collaborative editing between user and agent.
  • Multiple transports — A2UI runs over A2A, AG-UI, MCP, WebSockets, or REST.
  • "Standard" components renamed to "Basic" — concession that frontend teams plug in their own design systems.

The google/A2UI repo is the source of truth for spec, catalogs, renderers, and samples.

Adoption Signals

Early integrations cluster around Google's surfaces and the AG-UI / CopilotKit ecosystem:

Integration Status Source
Flutter GenUI SDK Uses A2UI "under the covers" for remote agents Google Developers Blog
AG-UI / CopilotKit Day-zero via npx copilotkit@latest create my-app --framework a2ui Google Developers Blog
Gemini Enterprise, Opal Internal Google adopters Google Developers Blog
Oracle Agent Spec Agent Spec + AG-UI + A2UI stack Oracle blog
Vercel json-renderer Experimental A2UI renderer Google Developers Blog
AG2 A2UIAgent Native integration from the AutoGen team Google Developers Blog

Cross-vendor backing is narrower than MCP's: A2UI is wider on frameworks, narrower on model providers.

A2UI vs MCP Apps

The two approaches solve the same problem with opposite trust models (The New Stack; A2UI docs):

Dimension A2UI MCP Apps
Payload Declarative JSON blueprint HTML resource at a ui:// URI
Rendering Host's own native components Sandboxed iframe
Design-system fidelity Inherits host styling Generic unless iframe is themed
Expressivity ceiling Catalog intersection Anything valid HTML/JS
Security model Data, not code Sandbox isolation
Cross-vendor backing Google + AG-UI / CopilotKit Anthropic, OpenAI (via MCP)

Neither has won. An upcoming bridge lets MCP servers return A2UI blueprints alongside HTML resources, suggesting coexistence rather than head-to-head competition.

When This Backfires

A2UI is the wrong choice in four situations:

  • Catalog-poor hosts: portability is bounded by host catalog ∩ agent references. The v0.9 "Standard" → "Basic" rename concedes there is no cross-host common set (Google Developers Blog).
  • Single-app single-framework deployments: the wire format earns its overhead across trust boundaries. For one React app with one design system, direct tool calls are cheaper.
  • Rapidly-iterating UI: the catalog is a static contract. Products changing UI weekly spend more time syncing the catalog and agent prompt than they save.
  • Consolidation risk: A2UI is pre-1.0, Google-led, and competes with MCP Apps, AG-UI native rendering, and OpenAI ChatKit. Picking it now bets on spec survival.

Example

A reservation agent emits the following A2UI blueprint in place of a text back-and-forth (adapted from Google's intro blog):

{
  "version": "0.9",
  "components": [
    {"id": "form", "type": "Card", "children": ["header", "date", "time", "submit"]},
    {"id": "header", "type": "Text", "props": {"text": "Book a table"}},
    {"id": "date", "type": "DatePicker", "props": {"label": "Date"}},
    {"id": "time", "type": "Select", "props": {
      "label": "Time",
      "options": ["5:00", "5:30", "6:00", "8:30", "9:00", "9:30", "10:00"]
    }},
    {"id": "submit", "type": "Button", "props": {"label": "Reserve", "action": "submit"}}
  ]
}

The host receives the blueprint over A2A, AG-UI, or MCP transport. It looks each type up in its catalog — Card, Text, DatePicker, Select, Button — and renders the form with its own styled components. The agent did not produce HTML; the host did not trust opaque code. The same blueprint, sent to a Flutter client, renders as native Flutter widgets.

Key Takeaways

  • A2UI is the wire format for agent-to-UI handoff: structured JSON blueprints referencing a host-declared component catalog.
  • The mechanism moves the trust boundary from UI to data — the host renders only components it pre-approved.
  • v0.9 ships Python Agent SDK, first-party renderers for Flutter / Lit / Angular / React, and transports over A2A, AG-UI, MCP, REST, and WebSockets.
  • The portability ceiling is the catalog intersection, not the spec — hosts with sparse design systems gain little.
  • MCP Apps occupies adjacent territory with an iframe-based trust model; neither standard has won as of v0.9.
  • The overhead earns out in multi-agent meshes and catalog-rich hosts; it does not earn out in single-framework single-team apps.
Feedback