What Is Google’s A2UI — and Should Developers Let Agents “Speak UI”?

# What Is Google’s A2UI — and Should Developers Let Agents “Speak UI”?

Google’s A2UI (Agent‑to‑UI) is an open-source, declarative protocol (currently v0.8 public preview) that lets an agent stream structured JSONL messages describing UI components, data bindings, and actions so a client can progressively render a native interface. Should developers let agents “speak UI”? Yes—but with guardrails. A2UI is explicitly designed to move UI generation away from arbitrary code execution and into a constrained, renderer-controlled declarative layer, but developers still have to treat the catalog (the allowed component/function contract) and the action/data pathways as security-critical.

A2UI in plain terms: an agent describes, your app decides

A2UI’s core idea is separation of concerns: the agent expresses UI intent—what should be shown, how it’s structured, what it’s bound to, and what interactions should be possible—while the client app (the renderer) stays authoritative about what actually gets displayed and what it’s allowed to do.

Instead of an LLM producing HTML or bespoke UI code, the agent streams a sequence of structured messages. The renderer consumes those messages and maps them onto the platform’s own UI toolkit—whether that’s web frameworks like React/Lit/Angular (via shared foundations such as @a2ui/web-lib) or native toolkits (e.g., Flutter), depending on the renderer implementation.

That’s the fundamental trade: less “agent runs UI code,” more “agent proposes a UI within a constrained schema.”

How A2UI works in practice (the technical essentials)

At its most practical level, A2UI is about streaming UI as data.

JSONL streaming for progressive rendering

A2UI uses JSON Lines (JSONL): the agent/server emits a stream of individual JSON objects, one per line. This design is intentionally LLM-friendly and pairs naturally with streaming model outputs. As each message arrives, the client can render partial UI immediately and then refine/update it as more messages stream in—an approach that improves perceived latency and supports interactive, incremental experiences.

A declarative component tree, not imperative code

The agent’s messages describe UI elements and their properties declaratively. The renderer interprets those descriptions to build or update the UI. The important point is that the renderer implements the actual widgets/components, not the agent. The agent is never “handed the keys” to execute code inside the UI runtime; it’s sending a structured description that the client can accept, reject, or constrain.

Catalogs: the contract that limits what an agent can ask for

A2UI’s safety and portability hinge on catalogs: an explicit contract enumerating what components and functions/actions exist and are allowed. The agent can only “speak” in terms that the renderer recognizes and has registered. If a renderer doesn’t register a component or function, the agent can’t rely on it.

This is also what makes A2UI framework-agnostic: the agent describes “a button” or “a form field” in A2UI terms, and the renderer maps that to native UI equivalents.

Data binding + two-way interaction

A2UI supports bindings between component properties and application/agent data—so UI can update as data changes, and data can reflect UI state. It also includes client-to-server actions: user interactions (clicks, submissions) can be sent back to the agent/server to continue the dialog or request an updated UI state.

That two-way loop is what turns “generated UI” into “agent-driven UI”: users interact, events go back, the agent streams updates, and the UI evolves.

Security model: why this isn’t “running agent code in your UI”

A2UI’s security posture starts with a simple premise: avoid shipping executable code from the agent. The agent provides a declarative description; the renderer decides how (or whether) to realize it.

That said, “declarative” doesn’t automatically mean “safe.” The key security mechanisms live on the renderer side:

• Catalog enforcement and renderer registration: Developers choose which components and functions are permitted and how they map to native capabilities. This is the main sandbox boundary.
• Validation and sanitization: Incoming streamed messages still need to be treated as untrusted input. Malformed or unexpected UI descriptions should be detectable and rejectable.
• Permission checks for side effects: Any action that triggers real-world effects (changing data, invoking backend operations, etc.) must be gated by application authorization rules, not by the agent’s suggestion.
• Catalog auditing: If your catalog includes powerful functions, you can accidentally create privilege-escalation paths. The catalog is effectively your agent’s allowed “surface area.”

If you’ve been tracking broader shifts toward agent-controlled interfaces, A2UI is one concrete attempt to make that shift safer by design. It’s also adjacent to the broader “agents speak UI” conversation covered in Today’s TechScan: Agents Speak UI, Thread‑safe Networking, and a few surprises.

Developer guidance: integrating A2UI safely and effectively

If you’re considering A2UI, the practical approach is to treat it like an integration boundary—similar to how you’d treat a third-party plugin API.

1. Treat the catalog as your security policy

• Only register vetted components and functions.
• Prefer “wrapper” components/functions that enforce input validation, throttling, or other safety checks before calling sensitive capabilities.

1. Keep authorization and critical logic local

• Use A2UI to express UI intent and state updates.
• Keep decisions about permissions and sensitive operations enforced in your app or backend—never implicitly granted because the agent asked.

1. Build monitoring, fallbacks, and “safe failure” behavior

• Log agent messages and action requests.
• Detect malformed/unexpected UI descriptions and fail closed.
• Provide a non-agent fallback UI path if streaming fails or the output becomes suspicious.

1. Start small

• Prototype with isolated, low-risk components such as read-only displays or simple forms.
• Expand toward side-effecting operations only after you’ve proven your catalog and action handling are robust.

A2UI is also part of a larger move toward standardizing how agents interact with user interfaces; if you want broader context on how agent-driven UI contracts can reshape app architecture, see What Is Google’s A2UI and How Will It Change Agent‑Driven UIs?.

Tooling and ecosystem: what’s available now

Google’s google/A2UI GitHub repository provides the source, the spec, examples, and client libraries, anchored around the v0.8 specification. The A2UI site also provides guides and client setup instructions, plus a Composer and quickstarts intended to speed up prototyping.

On the web, framework-specific renderers (such as React/Lit/Angular) are designed to share a common base via @a2ui/web-lib, aiming for consistent behavior across frameworks. A2UI is also explicitly designed to be extended with custom components and theming/styling—useful, but it increases the importance of review and auditing because extensions expand the catalog surface.

Why It Matters Now

Google has put A2UI into public preview with a published v0.8 spec and an open-source repository, which is a strong signal that “agent-driven interfaces” are moving from demos into something developers can standardize around. The protocol’s emphasis on streaming aligns with the practical reality of how modern LLMs are delivered (incremental tokens, incremental output), and its progressive rendering model matches user expectations for low-latency, responsive experiences.

Just as importantly, A2UI is framework-agnostic: the same agent output can, in principle, drive UIs across different clients as long as each implements a compatible renderer and catalog. That interoperability is attractive for teams building multi-platform apps and enterprise workflows where “the agent experience” should feel consistent across surfaces.

What to Watch

• Spec evolution beyond v0.8: expect changes; plan versioning and compatibility strategies.
• Real-world security patterns: watch for concrete guidance and examples around catalogs, action gating, and safe defaults.
• Ecosystem maturity: community renderers, shared libraries, and operational tooling (validation, observability) will determine how “production-ready” A2UI feels outside prototypes.
• Interoperability norms: whether catalogs and component conventions converge—or fragment—will shape whether A2UI becomes a true cross-platform layer.

Sources: https://a2ui.org/specification/v0.8-a2ui/ | https://docs.copilotkit.ai/learn/generative-ui/specs/a2ui | https://github.com/google/A2UI | https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/ | https://deepwiki.com/CopilotKit/generative-ui/4.1-a2ui-specification | https://a2ui.org/guides/client-setup/