Google Opal: Building AI Mini-Apps with A2UI

Google Opal is one of the first Google products to bet entirely on generative UI: instead of shipping a fixed front-end, the interface itself is produced by an AI at runtime. Hundreds of thousands of people now build, edit, and share AI “mini-apps” in Opal using nothing but natural language — and the protocol making that possible is A2UI, the same open protocol behind Flutter’s GenUI SDK.

Sources: A2UI in the World, a2ui.org, and opal.google.

What Google Opal is

Opal is a Google product for building small, single-purpose AI apps — mini-apps — through conversation. You describe what you want (“a workout planner that asks my goals and generates a weekly schedule”), Opal’s AI assembles the workflow and the interface, and you can keep refining it in plain language. The result can be shared with others, who can fork and edit it the same way.

The key detail for developers: Opal’s UI is not a template library with slots. It is generated per app, per use case, by the model.

How Opal uses A2UI

A2UI (Agent-to-UI) is an open protocol that defines how AI agents and UI renderers collaborate on the composition and state of an interface. An agent doesn’t send raw markup or a screenshot — it sends structured, declarative UI descriptions, and a renderer that implements the protocol turns them into native components.

The Opal team at Google has been a core contributor to A2UI from the beginning. Per the A2UI ecosystem documentation, Opal uses A2UI to power the dynamic, generative UI system behind its mini-apps:

• Rapid prototyping — new UI patterns can be built and tested quickly, because changing the interface means changing a prompt or schema, not shipping a new front-end build.
• User-generated apps — anyone can create apps with custom UIs, since the UI is derived from intent rather than hand-coded.
• Dynamic interfaces — the UI adapts to each use case automatically instead of forcing every app through one generic layout.

Dimitri Glazkov, Principal Engineer on the Opal team, has described A2UI as foundational to the work:

“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.”

That last point matters: because A2UI messages are declarative data (a component tree with bindings and actions), a client can validate, sandbox, and style them before anything renders — which is far safer than letting a model emit arbitrary HTML or executable code.

Why Flutter developers should care

Opal is the largest production example of the pattern Flutter is betting on with the GenUI SDK. When you use package:genui in a Flutter app, you are using A2UI under the covers: your agent speaks the same protocol that powers Opal’s mini-apps, and your app renders it as native Flutter widgets on iOS, Android, web, and desktop.

The ecosystem page highlights four production deployments of A2UI today:

1. Google Opal — consumer AI mini-apps.
2. Gemini Enterprise — AI-generated forms, approval dashboards, and workflow UIs for business agents.
3. Flutter GenUI SDK — generative UI for Flutter apps across platforms.
4. Google ADK — the Agent Development Kit, whose ADK Web UI renders A2UI natively and converts A2UI messages to A2A events.

On top of those, partner integrations include AG-UI/CopilotKit (day-zero A2UI compatibility for React, Vue, and Angular surfaces) and AG2’s A2UIAgent, which serves the same UI over both A2A (JSON-RPC) and AG-UI (SSE) transports — including an example of an AG2 agent driving a Flutter GenUI client.

The architecture lesson behind Opal

Whether or not you build with Opal, the pattern it validates is worth stealing:

1. Intent in, structure out. The model produces declarative UI descriptions (A2UI messages), not pixels and not code.
2. The renderer owns the design system. Opal’s generated UIs still look and behave consistently because the client — not the model — decides how components map to real widgets, theming, and accessibility.
3. The protocol is the portability layer. Because A2UI is open and framework-agnostic, the same agent output can drive a Flutter app, a React dashboard, or Google’s internal tools.
4. Security comes from the protocol boundary. Validation happens on the client, where you can enforce what an agent is allowed to render and which actions it may trigger.

For Flutter teams, this means the GenUI skills you build today — writing system prompts with PromptBuilder, defining widget catalogs, wiring A2uiTransportAdapter to your agent — are directly transferable to the same protocol powering one of Google’s flagship AI products.

Getting started

• Try opal.google to feel the interaction model first-hand.
• Read the A2UI ecosystem page for the full list of production and partner deployments.
• Follow the Flutter GenUI documentation and the Verdure example to build the client side in Flutter.
• Explore the A2UI repository for quickstarts, the component gallery, and agent-development guides.

Generative UI is no longer a demo — it is shipping in production at Google, and the mini-apps Opal users create every day are proof that letting the model decide how content is presented, not just what it says, is becoming a mainstream product pattern.