Google A2UI: When AI Agents Learn to Speak UI

AI agents can write code. They can search the web. They can execute shell commands. But ask them to show you a beautiful, interactive dashboard? They’ll give you a wall of text.

Google just open-sourced a solution: A2UI (Agent-to-User Interface) — and it already has 12.9K stars on GitHub.

GitHub: github.com/google/A2UI (Apache 2.0)

Today’s AI agents communicate through text. When an agent needs to show you structured information — a comparison table, a booking form, a data visualization — it’s stuck with markdown at best, or raw JSON at worst.

This is a fundamental limitation:

Chat-only interfaces can’t handle complex interactions (date pickers, sliders, multi-step forms)
Code generation (generating React/HTML) is a security nightmare — you’d be running LLM-generated code
Cross-platform is impossible — an agent can’t generate both Flutter widgets AND React components

A2UI: Safe Like Data, Expressive Like Code

Google’s approach is elegant: agents send declarative JSON describing the intent of a UI, not the implementation.

{
  "type": "card",
  "children": [
    { "type": "text", "content": "Restaurant Found" },
    { "type": "image", "src": "https://..." },
    { "type": "button", "label": "Book Now", "action": "book" }
  ]
}

The client application maps these abstract components to its own native widgets — React components, Flutter widgets, SwiftUI views, or anything else.

Why This Matters

Security first: No executable code from the LLM. The agent can only request components from a pre-approved catalog
LLM-friendly: Flat list of components with IDs — easy for models to generate incrementally
Framework-agnostic: Same JSON payload renders on web, mobile, desktop
Incrementally updatable: Agents can update specific components without regenerating the entire UI

Architecture: 4-Step Flow

Agent (LLM) → A2UI JSON → Transport (A2A/AG UI) → Client Renderer → Native UI

Generation: Agent creates a JSON payload describing UI components
Transport: Sent via Google’s A2A protocol, AG UI, or any transport
Resolution: Client’s A2UI Renderer parses the JSON
Rendering: Abstract components mapped to native implementations

Real Use Cases

This isn’t theoretical. A2UI enables scenarios that pure text agents can’t handle:

Dynamic forms: An agent generates a booking form with date pickers and sliders based on conversation context
Remote sub-agents: A travel agent returns a rich UI card inside the chat window of an orchestrator agent
Adaptive dashboards: Enterprise agents generate approval workflows and data visualizations on the fly

What This Means for Claude Code Developers

If you’re building with Claude Code, A2UI opens new possibilities:

Agent Teams with UI Output

Imagine Claude Code Agent Teams where each agent can return rich UI components instead of just text. A code review agent could return an interactive diff viewer. A deployment agent could show a real-time status dashboard.

MCP + A2UI Integration

MCP servers currently return text results. With A2UI, an MCP server could return structured UI components that the client renders natively. Your custom MCP tool could show a chart, a form, or an interactive table.

Beyond the Terminal

Claude Code today lives in the terminal. A2UI provides a standard for what happens when agents break out of text-only interfaces — and it’s an open standard, not locked to any vendor.

The Competitive Landscape

A2UI doesn’t exist in a vacuum:

Approach	Pros	Cons
A2UI (Google)	Security-first, framework-agnostic, open standard	Early stage (v0.8), limited renderers
AG UI	Real-time streaming, React-focused	Tightly coupled to React ecosystem
Raw HTML/React generation	Maximum flexibility	Security risk, single-framework
Markdown	Universal, simple	No interactivity, limited layout

A2UI’s bet is that security + portability matters more than maximum expressiveness. Given the enterprise market, that’s likely the right bet.

Getting Started

git clone https://github.com/google/A2UI.git
cd A2UI
export GEMINI_API_KEY="your_key"

# Run the restaurant finder demo
cd samples/agent/adk/restaurant_finder
uv run .

Currently supports:

Renderers: Lit (web), Flutter (mobile)
Agent frameworks: Google ADK, with LangGraph/Genkit coming
Transports: A2A Protocol, AG UI

Our Take

A2UI solves a real problem. The terminal-only era of AI agents is ending. As agents become more capable (Claude Code can already manage entire projects autonomously), they need richer ways to communicate with humans.

The question isn’t whether agents will generate UIs — it’s which standard wins. Google has the advantage of:

Open source (Apache 2.0)
Framework neutrality
Security-first design
Existing ecosystem (Flutter, Angular, Android)

What’s missing: React support (the web’s dominant framework) and more agent framework integrations. Both are on the roadmap.

The bottom line: If you’re building AI agents that interact with humans, bookmark A2UI. It’s v0.8 today, but the concept — agents speaking UI through a safe, declarative format — is the future.

Source: github.com/google/A2UI

The Problem: Agents Are Blind to UI