A2UI in Google Opal: How a No-Code Mini-App Builder Runs on a UI Protocol

A2UI isn’t a demo protocol. The A2UI ecosystem page lists it in production at Google, and the first entry is Google Opal — a product that lets hundreds of thousands of people build, edit, and share AI mini-apps using natural language, no coding required. If you’ve ever wondered what “server-driven UI” looks like when an LLM is the server, Opal is the clearest answer shipping today.

Here’s what the ecosystem page actually documents about Opal, and what it means if you’re building generative UI yourself.

What Opal uses A2UI for

The Opal team has been a core contributor to A2UI from the beginning. Per the ecosystem page, they use A2UI to power the dynamic, generative UI system that makes the mini-apps possible, with three stated payoffs:

• Rapid prototyping — build and test new UI patterns quickly.
• User-generated apps — anyone can create apps with custom UIs.
• Dynamic interfaces — the UI adapts to each use case automatically.

The page carries a quote from Dimitri Glazkov, Principal Engineer on the Opal team:

“A2UI is foundational to our work. It gives us the flexibility to let the AI drive the user experience in novel ways, without being constrained by a fixed front-end. Its declarative nature and focus on security allow us to experiment quickly and safely.”

Two words in that quote carry weight for implementers: declarative and security. A2UI messages describe a component tree and data bindings rather than executable code, so a model can compose a screen without shipping arbitrary behavior to the client. That’s the property that makes it viable for a product where the “developer” is a non-programmer typing prompts.

Why a protocol, not an in-house format

Opal could have invented a private JSON dialect. The choice to standardize shows up across the rest of the ecosystem page:

• Gemini Enterprise uses A2UI so enterprise agents render rich, interactive UI inside business applications — AI-generated data entry forms, approval dashboards, step-by-step workflow interfaces. (The page notes a real constraint: rendering currently requires self-serve agents registered via the A2A path, a2aAgentDefinition; managed agents on Vertex AI Agent Engine using adkAgentDefinition don’t support A2UI rendering yet.)
• Flutter’s GenUI SDK uses A2UI as its underlying wire protocol. The page is blunt about it: “When you use GenUI, you’re using A2UI under the covers.” Vijay Menon, Engineering Director for Dart & Flutter, is quoted explaining that A2UI fit Flutter because it keeps a native-feeling, brand-consistent experience on every platform.
• Google ADK integrates A2UI so the ADK Web developer UI renders spec-compliant agent parts natively in chat, and converts A2UI messages to and from A2A DataPart metadata.

The standardization point is made by James Wren, Senior Staff Engineer, AI Powered Google: much as A2A lets agents talk across platforms, “A2UI standardizes the user interface layer and supports remote agent use cases through an orchestrator,” letting internal teams treat rich UI as the norm rather than the exception.

The rest of the adoption map

Beyond Google’s own products, the ecosystem page records partner and community work worth knowing before you bet on the protocol:

• AG-UI / CopilotKit — day-zero A2UI compatibility, so state-synced React/Vue/Angular apps can render UIs from third-party agents.
• AG2 — its A2UIAgent reference agent adds prompt engineering, schema validation with retry, and action handling, and serves the same UI over both A2A (JSON-RPC) and AG-UI (SSE). There’s a published example pairing AG2’s A2UIAgent with a Flutter GenUI client.
• Vercel’s json-render — a React library that renders A2UI component catalogs through Zod schemas.
• OpenClaw Canvas — renders agent-generated UI on connected devices via A2UI.
• Sample agents (a Gemini-powered restaurant finder with dynamic reservation forms) and a component gallery live in the a2ui-project repo.

What this means for Flutter developers

If you’re on Flutter, the Opal story translates into three practical takeaways:

1. You don’t have to write a renderer. The GenUI SDK already is one: SurfaceController, Catalog, and Surface consume A2UI messages over A2uiTransportAdapter, with the genui package on pub.dev and an A2A connector for server agents.
2. Catalogs are your design system. Opal’s “dynamic interfaces adapt to each use case” works because the allowed component set is defined up front. Define your CatalogItems with schemas, and generation stays on-brand instead of hallucinating layouts.
3. Protocol versioning matters. The spec site currently ships v0.9.1 as current with a v1.0 candidate, plus an evolution guide — check which version your server agent and renderer agree on before you build.

The headline lesson from Opal is the division of labor: the model chooses what to render, the protocol constrains how it’s described, and the renderer — your Flutter widget catalog — guarantees quality. Keep all three separated and generative UI stops being a novelty and starts being a shippable architecture.

Sources

• A2UI in the World — ecosystem page
• Google Opal
• GenUI SDK for Flutter