A2UI: Framework-Agnostic Generative UI Standard¶

A2UI is an open standard for agents to emit declarative UI blueprints that a host renders with its own native components.

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 SDK — pip 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.