Introduction

TL;DR

Google unveiled A2UI (Agent-to-User Interface) in December 2025 as an open-source protocol enabling AI agents to dynamically generate user interfaces using declarative JSON instead of text-based multi-turn dialogue. Designed around three core pillars—Security-First (Data, not Code), LLM-Friendly Architecture, and Framework-Agnostic Portability—A2UI is now in v0.8 stable release and actively deployed in production systems including Google Opal, Gemini Enterprise, and Flutter GenUI. This protocol fundamentally shifts how AI agents interact with users: instead of verbose text exchanges, agents now “speak UI” by composing context-appropriate components that render natively on any platform.

Context

Generative AI excels at producing text and images, but orchestrating rich, interactive user interfaces across trust boundaries has remained a significant challenge. Traditional approaches either sacrifice security (via embedded HTML/JavaScript) or limit flexibility (fixed UI templates). A2UI bridges this gap by establishing a standardized, declarative format that separates UI specification (agent responsibility) from UI rendering (client responsibility). This design enables secure remote agents to guide users through complex workflows—from restaurant reservations to enterprise data entry—without exposing systems to code injection vulnerabilities.


The Problem: Text-Heavy, Multi-Turn Interactions

Why Text-Only Responses Fall Short

Current AI agents rely heavily on text responses, forcing inefficient back-and-forth dialogues. Consider a simple restaurant reservation:

1
2
3
4
5
6
User: "Book a table for 2."
Agent: "When would you like to dine?"
User: "Tomorrow."
Agent: "What time?"
User: "Around 7 PM."
Agent: "That slot is full. Available times: 5:00, 5:30, 6:00, 8:30, 9:00, 9:30, 10:00..."

This “20 questions” pattern creates cognitive load and requires multiple typing cycles. For structured tasks like data entry, approval workflows, or configuration—common in enterprise environments—the friction becomes prohibitive.

Why This Matters

Text-only interfaces seem simple in theory but impose steep costs in practice. Users must repeatedly type, agents must continually clarify, and the overall user experience degrades. The problem intensifies when agents need to present options (date/time slots), request structured input (forms), or guide multi-step workflows (approval chains). A2UI addresses this by enabling agents to request context-appropriate UI components instead of narrating them.


The A2UI Solution: “Agents Speak UI”

The Core Philosophy

A2UI introduces a paradigm shift: “Let agents speak the language of UI.” Rather than describing what UI to build, agents compose declarative JSON that describes a component structure. The client then renders this description using its own native widgets, inheriting the app’s styling, accessibility, and performance characteristics.

A2UI in Action: Restaurant Booking Example

With A2UI:

  1. User input: “Book a table for 2.”
  2. Agent response: Generates one compact JSON message describing a form with:
    • Date picker (for restaurant opening hours)
    • Time selector (pre-filtered by availability)
    • Submit button
  3. User action: Clicks to select date/time, then submits
  4. Agent processing: Immediately confirms booking

The entire workflow completes in two turns (vs. five+ in text-only mode) and requires minimal typing.

Why It Matters

A2UI shifts agents from “narrating UI” to “providing tools.” This resembles handing a user a date picker widget instead of asking “What date?” five different ways. The efficiency gain is substantial, especially for data-rich or workflow-heavy applications.


A2UI’s Three Core Design Pillars

1. Security First: Data, Not Code

The most critical feature of A2UI is its security model: UI is transmitted as declarative data, never executable code.

DimensionTraditional ApproachA2UI
PayloadHTML/JavaScriptDeclarative JSON
Executioniframe sandboxing requiredNo code execution
Risk VectorUI injection, XSSRestricted to pre-approved components
Component ControlRemote serverClient-side trusted catalog

How it works:

The client maintains a trusted component catalog (Card, Button, TextField, DatePicker, etc.). Remote agents can only request rendering of components in this catalog. Any attempt to inject arbitrary code, manipulate the DOM, or invoke undefined components is structurally impossible. This eliminates entire classes of security vulnerabilities.

Why it matters for enterprises:

When remote agents—whether internal microservices or third-party integrations—need to render UI across trust boundaries, code execution is unacceptable. A2UI provides a formally bounded security model: what the agent can do is limited to what the client has approved. This is essential for regulated industries (finance, healthcare, government) deploying agentic systems.

2. LLM-Friendly Structure: Flat, Streaming Design

Most UI specifications use nested tree structures (DOM-like hierarchies). While expressive, these are difficult for LLMs to generate reliably. A2UI uses a flat adjacency-list representation optimized for language model generation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
  "components": [
    { "id": "1", "type": "text", "content": "Reservation Details" },
    { "id": "2", "type": "date-picker", "label": "Date" },
    { "id": "3", "type": "time-selector", "label": "Time" },
    { "id": "4", "type": "button", "label": "Book", "onClick": "submit" }
  ],
  "layout": {
    "surface": "main",
    "children": ["1", "2", "3", "4"]
  }
}

Advantages:

  • Incremental Generation: LLMs don’t need to produce perfect JSON in one pass. They can generate components sequentially, updating the UI as computation progresses.
  • Streaming Support: As conversation continues, the agent sends only changed components (via dataModelUpdate messages), not the entire UI. Users see progressive refinement in real-time.
  • Token Efficiency: Flat lists consume fewer tokens than deeply nested structures, leaving more context budget for actual task logic.

Why it matters for LLM deployment:

LLMs are genuinely poor at generating deeply nested JSON reliably. A2UI’s flat design aligns with how Transformers naturally generate structured output, dramatically improving reliability and reducing the need for prompt engineering workarounds.

3. Framework-Agnostic Rendering

A2UI strictly separates specification from implementation. The agent describes what components to show; the client decides how to render them.

One payload, multiple renderers:

1
2
3
4
5
6
Agent generates:
{ "type": "card", "children": [{ "type": "text", "content": "Hello" }] }

Web (React):      → <Card><Text>Hello</Text></Card>
Mobile (Flutter): → Card(child: Text("Hello"))
Desktop (SwiftUI): → Card { Text("Hello") }

Each platform inherits its own design system, accessibility features, and performance optimizations. No iframes, no style clashes, no legacy browser compatibility issues.

Why it matters for product teams:

Shipping consistently-styled UIs across web, iOS, Android, and desktop is notoriously complex. A2UI allows agent logic to be written once, and rendered natively everywhere. Design systems stay unified without duplicating logic across platforms.


A2UI Architecture and Data Flow

The Four-Stage Pipeline

A2UI separates concerns into four discrete layers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
┌─────────────────────┐
│   User Message      │
│   (Text Input)      │
└──────────┬──────────┘
           v
┌──────────────────────────┐
│  A2A Agent Backend       │ ← Python/Node.js
│  (Orchestration Layer)   │
└──────────┬───────────────┘
           v
┌──────────────────────────┐
│   Gemini API             │ ← LLM generates JSON
│   (Generative AI)        │
└──────────┬───────────────┘
   (A2UI JSON JSONL Stream)
           v
┌──────────────────────────┐
│  Client A2UI Renderer    │ ← Lit, React, Angular, Flutter
│  (Interpretation Layer)  │
└──────────┬───────────────┘
   (Native Component Binding)
           v
┌──────────────────────────┐
│   Final UI Rendering     │
│   (Native Widgets)       │
└──────────────────────────┘

Message Types in the JSONL Stream

A2UI uses JSON Lines (JSONL) format, allowing agents to stream messages incrementally:

Message TypePurposeExample
surfaceUpdateAdd or modify components in a UI surfaceAppend a date picker to a form
dataModelUpdateUpdate data binding valuesChange available time slots as user selects a date
eventHandlerRespond to user actions (clicks, form submissions)Process booking when user clicks “Confirm”

This streaming design enables progressive rendering: users see the interface materialize in real-time rather than waiting for a complete server response.

Standard Catalog (v0.8)

A2UI v0.8 defines a standard component catalog accessible at:
https://github.com/google/A2UI/blob/main/specification/0.8/json/standard_catalog_definition.json

Standard components include:

  • Layout: Surface, Card, Row, Column, Spacer, Divider
  • Input: TextField, Button, Checkbox, RadioGroup, Slider, DatePicker, TimePicker, Select, Dropdown
  • Display: Text, Image, Icon, Badge, Link
  • Advanced: List, Table, Timeline, CustomComponent (for platform-specific widgets like Google Maps)

Clients can also define custom components for domain-specific needs (interactive charts, real-time data visualizations, etc.), enabling extensibility without breaking compatibility.

Why It Matters

By layering specification separately from transport and rendering, A2UI becomes:

  • Resilient: Changes to one layer (e.g., adding a new renderer) don’t affect others
  • Scalable: New platforms can adopt A2UI without modifying agent logic
  • Debuggable: Each layer can be tested and monitored independently

Security Model: How A2UI Prevents UI Injection

The Threat: Why HTML/JS Payloads Are Dangerous

Traditional remote UI rendering sends executable code (HTML/JavaScript) to clients. An attacker controlling the agent could:

  • Inject malicious scripts
  • Steal user credentials or session tokens
  • Manipulate form data before submission
  • Deface the UI to trick users into fraudulent actions

Sandboxing via iframes mitigates some risks but is complex, has performance overhead, and still leaves subtle vulnerabilities.

The A2UI Mitigation: Catalog-Based Whitelisting

A2UI eliminates this entire attack surface by restricting agents to a pre-approved component catalog:

  1. Client defines catalog: “I will only render Card, Button, TextField, DatePicker from this JSON schema.”
  2. Agent generates only catalog references: JSON like { "type": "card", "children": [...] }
  3. Renderer validates: Before rendering, the client verifies every component type is in the catalog.
  4. No code execution: Even if an attacker tries { "type": "__proto__.polluted": true }, it simply fails validation.

Security guarantees:

  • ✅ No arbitrary code execution
  • ✅ No prototype pollution (with proper patch libraries)
  • ✅ No DOM manipulation outside approved components
  • ✅ Client retains full control over what can be rendered

Why it matters for compliance:

Enterprises operating under regulatory frameworks (HIPAA, PCI-DSS, SOC 2) require formal security boundaries. A2UI’s declarative model makes those boundaries explicit and auditable.


A2UI in Production: Real-World Deployments

Google Opal: AI Mini-Apps for Everyone

Google Opal enables non-technical users to build, edit, and share AI-powered applications using only natural language—no coding required.

How A2UI powers Opal:

  • Rapid UI Prototyping: Developers iterate on agent logic without writing UI code
  • User-Generated Apps: End users create custom AI apps, each with dynamically generated UIs tailored to their specific use case
  • Scalable to Millions: Opal uses A2UI to serve hundreds of thousands of mini-app creators, each with unique interface requirements

Impact: What would have required weeks of hand-coded UI now takes minutes of natural-language prompting.

Gemini Enterprise: AI-Powered Business Workflows

Gemini Enterprise helps organizations build custom AI agents tailored to their workflows and data.

A2UI enables:

  • Data Entry Forms: Agents generate context-aware input forms. If a form requires budget approval, the agent dynamically includes budget fields. If it’s a simple status update, fields are minimal.
  • Approval Dashboards: Complex approval workflows are guided by step-by-step interfaces. Users don’t navigate menus; the agent presents the next action.
  • Workflow Automation: Multi-step processes (e.g., hire a contractor → request approval → process payment) are orchestrated through dynamic UIs.

Quote from Google Gemini Enterprise:

“Customers don’t just need agents that answer questions; they need agents that guide them through complex workflows. A2UI allows developers to have agents generate the custom, dynamic UIs needed for everything from data entry to approval dashboards, dramatically accelerating workflow automation.”

Flutter GenUI SDK: Cross-Platform Native Rendering

Flutter’s GenUI SDK integrates A2UI to enable developers to generate personalized native mobile UIs while maintaining brand design consistency.

Benefits:

  • Brand Uniformity: All generated UIs inherit the brand’s color palette, typography, and component library
  • Cross-Platform: One agent response renders as native iOS (SwiftUI), native Android (Jetpack Compose), and web (Flutter Web)
  • Performance: Native rendering means no JavaScript bridge overhead, smooth animations, and true accessibility support

Why These Matter

These three production deployments span different domains (consumer apps, enterprise workflows, mobile development) and all report successful, scalable operation. This proves A2UI is not theoretical—it’s hardening in real systems.


A2UI vs. Alternative Approaches

A2UI vs. MCP (Model Context Protocol)

MCP and A2UI serve different purposes and can coexist:

AspectA2UIMCP
PurposeUI rendering standardTool/API invocation standard
PayloadUI component definitionsFunction signatures and tool descriptions
Use CaseHow agents show informationHow agents access external tools
ExampleAgent sends a chart component to display sales dataAgent calls a “fetch_sales_data” tool via MCP

Synergy: An agent using MCP to fetch data and A2UI to render a visualization exemplifies how they complement each other.

A2UI vs. AG-UI

AG-UI and A2UI operate at different layers:

LayerAG-UIA2UI
RoleTransport/Event ProtocolUI Definition Payload
ResponsibilityDeliver messages between agent and clientDefine what components to render

Relationship: AG-UI is the delivery mechanism; A2UI is the package specification. Many deployments use AG-UI to transport A2UI messages.

A2UI vs. Traditional HTML/JavaScript Remote Rendering

DimensionA2UIHTML/JS Approach
SecurityData-only, no code executionRequires iframe sandboxing; XSS risks remain
Native IntegrationInherits host app styling & a11yiFrame styling mismatch; accessibility gaps
PerformanceLightweight JSON parsingHeavy DOM parsing; JavaScript execution overhead
DebuggabilityDeclarative (audit-friendly)Imperative (hard to trace)

A2UI’s declarative model fundamentally eliminates categories of vulnerabilities while improving user experience.


Getting Started: A2UI Quickstart (5 Minutes)

Prerequisites

  • Node.js and Python installed
  • Gemini API Key (free tier available at ai.google.dev)

Setup and Execution

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# 1. Clone the repository
git clone https://github.com/google/a2ui.git
cd a2ui

# 2. Set your Gemini API key
export GEMINI_API_KEY="your_key_here"

# 3. Start the backend agent (Terminal 1)
cd samples/agent/adk/restaurant_finder
uv run .

# 4. Start the frontend renderer (Terminal 2)
cd samples/client/lit/shell
npm install
npm run dev

# 5. Open your browser
# Navigate to http://localhost:5173

Explore Additional Demos

1
2
3
4
5
# Component gallery (no agent required)
npm start -- gallery

# Contact lookup demo (showcases data binding)
npm run demo:contact

What you’ll experience:

  • Real-time UI generation by Gemini
  • Dynamic form fields based on agent reasoning
  • Streaming JSONL messages visualized in the client
  • Native component rendering with framework-appropriate styling

Why It Matters

The 5-minute quickstart lowers the barrier to experimentation. Engineers can validate A2UI’s approach without significant setup investment.


Impact and Metrics

Quantified Benefits

Teams adopting A2UI report:

  • 30% reduction in UI implementation time: Dynamic generation replaces hand-coding
  • Fewer defects: Declarative data is easier to validate and test than imperative UI logic
  • Faster iteration cycles: Prototype → test → deploy cycles accelerate when UI is generated, not written

Real-World Example: E-Commerce

An e-commerce platform using A2UI can:

  • Dynamically generate product filters based on category metadata (no code changes needed when adding new filters)
  • Adapt checkout flows based on payment methods (agents insert payment-specific fields at runtime)
  • Personalize product recommendations UI (different layouts for different user segments)

Previously, each variant required separate development and testing. A2UI generates them on demand.

Why It Matters

Quantifiable productivity gains (30% faster development) translate to faster time-to-market, lower engineering costs, and ability to ship more features.


Current State and Roadmap

Version Status

  • v0.8: Stable, production-ready release
  • v0.9: Draft specification under development
  • License: Apache 2.0

Available Renderers (as of December 2025)

  • Lit (JavaScript Web Components) ✅
  • React (via community contributions) ✅
  • Angular ✅
  • Flutter ✅
  • More in development (SwiftUI, Jetpack Compose)

Ecosystem

  • Official repository: github.com/google/a2ui
  • Documentation: a2ui.org
  • Community tools: A2UI Composer (by CopilotKit) for UI prototyping

Why It Matters

Stable v0.8 with production deployments signals that A2UI has moved beyond research. Teams can adopt it now without bet-the-company risk.


Conclusion

A2UI represents a fundamental rethinking of how AI agents and user interfaces interact. By treating UI as declarative data rather than executable code, it solves three critical problems simultaneously:

  1. Security: Eliminates code injection vulnerabilities through catalog-based whitelisting
  2. Efficiency: Replaces verbose text dialogues with composable UI components, reducing interaction turns
  3. Portability: Enables single agent logic to render natively across web, mobile, and desktop

With production deployments at Google Opal, Gemini Enterprise, and Flutter, v0.8 stable release, and an Apache 2.0 open-source license, A2UI is ready for enterprise adoption. As AI agents increasingly orchestrate complex workflows (data entry, approvals, customer support), A2UI provides the standardized, secure, native interface layer that makes agents genuinely useful.

The future of agent-user interaction is not text-heavy back-and-forth—it’s agents speaking the language of UI.


Summary

  • What: A2UI is Google’s open-source protocol enabling AI agents to generate secure, native UIs declaratively
  • Why: Text-only agent responses create friction; A2UI enables dynamic UI composition with security guarantees
  • How: Agents send declarative JSON; clients render using pre-approved components from a trusted catalog
  • Status: v0.8 stable; production deployments at Google Opal, Gemini Enterprise, Flutter GenUI
  • Key Principles: Security-first (data, not code), LLM-friendly (flat, streaming), framework-agnostic (render anywhere)
  • Next Steps: Clone the repo, run the quickstart, and experience agent-generated UIs firsthand

#A2UI #Google #AIAgents #UIGeneration #DeclarativeUI #Gemini #LLM #Protocol #OpenSource #CloudNative #AgentArchitecture


References

  • (A2UI Official Specification v0.8, 2025-09-18)[https://a2ui.org/specification/v0.8-a2ui/]
  • (Introducing A2UI: An open project for agent-driven interfaces, 2025-12-14)[https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/]
  • (Google Introduces A2UI: An Open Source Protocol for Agent-Driven Interfaces, 2025-12-21)[https://www.marktechpost.com/2025/12/22/google-introduces-a2ui-agent-to-user-interface-an-open-sourc-protocol-for-agent-driven-i]
  • (Quickstart: Run A2UI in 5 Minutes, 2025-12-14)[https://a2ui.org/quickstart/]
  • (What is A2UI?, 2025-12-15)[https://a2ui.org/introduction/what-is-a2ui/]
  • (Where is A2UI Used?, 2025-12-15)[https://a2ui.org/introduction/where-is-it-used/]
  • (Claude Skills vs. MCP: A Technical Comparison for AI Assistants, 2025-12-17)[https://intuitionlabs.ai/articles/claude-skills-vs-mcp]
  • (A2UI Review: Features, Use Cases & Integration Guide, 2025-12-19)[https://www.toolworthy.ai/tool/google-a2ui]
  • (A2UI Agent-Driven Interfaces: Transforming User Experience, 2025-12-15)[https://thewallstreetmarketing.com/2025/12/a2ui-agent-driven-interfaces/]
  • (A2UI Protocol: Google’s New Agent-Driven Interface Standard, 2025-12-15)[https://getdiffer.com/blog/a2ui-protocol-googles-new-agent-driven-interface-standard]
  • (A2UI - An open-source declarative UI specification and toolkit, 2025-12-19)[https://jimmysong.io/ai/a2ui/]
  • (AG-UI: A Lightweight Protocol for Agent-User Interaction, 2025-12-18)[https://www.datacamp.com/tutorial/ag-ui]
  • (A2UI - Practical Applications in Production, 2025-11-21)[https://ht-x.com/en/posts/2025/11/a2ui/]
  • (Mitigating the Risk of Prompt Injections in Browser Use, 2025-11-23)[https://www.anthropic.com/research/prompt-injection-defenses]
  • (A2UI(Agent-to-User Interface) Introduction, 2025-12-14)[https://discuss.pytorch.kr/t/a2ui-agent-to-user-interface-ai-ui/8431]