Last week, Google released version 0.9 of the A2UI protocol—bringing us one step closer to a development that will fundamentally transform the foundation of mobile app development: Generative UI allows AI agents to generate customized interface widgets in real time, adapting the interface state to match individual user interactions. The goal is clear: moving from demo scenarios to production readiness. A2UI v0.9 is Google’s answer—a framework-agnostic standard for declaring UI intentions. Flutter plays a central role in this ecosystem.
What has happened technically?
A2UI is an open standard and a set of libraries that allows agents to “speak UI.” Agents send a declarative JSON format that describes the UI’s intent. The client application then renders this description using its own native component library—be it Flutter, Angular, or Lit. This approach ensures that agent-rendered UIs are as secure as data but as expressive as code. The Flutter-specific arm of this ecosystem is the GenUI SDK for Flutter, now available in alpha on pub.dev. The SDK helps generate dynamic, personalized UIs using Gemini or other LLMs—in accordance with brand guidelines and the existing widget catalog.
Technically, the interaction works through three core components: a `SurfaceController` that manages the widget catalog and applies UI updates, an `A2uiTransportAdapter` that parses the raw LLM response streams, and a `Conversation` object that orchestrates the entire interaction cycle. User interactions—clicks, text inputs—update a client-side data model, which is sent back to the AI as context for the next conversation step. Widgets automatically rebuild when the bound data in the model changes.
The key v0.9 upgrade lies in the reliability of generation: v0.8 was still based on structured output—strict JSON schema constraints to keep the model in check. Neat in theory. In practice, LLMs repeatedly broke down when dealing with complex nested structures at scale. v0.9 flips this approach on its head: the schema and use cases flow directly into the system prompt. The model generates freely, a validator catches errors, and the agent corrects itself before anything reaches the client. This is not a cosmetic update—it is the prerequisite for true production operation.
Why is this strategically significant?
Anyone who underestimates the implications is thinking too short-term. Google is fundamentally changing app architecture to enable so-called “Agentic UIs”—interfaces that aren’t statically built in advance but adapt to user intent in real time. This is made possible by the Flutter GenUI SDK and the A2UI protocol, which allows AI models to dynamically generate rich experiences.
Dynamic rendering does not spell the end of frontend engineering. Companies still need dedicated engineering teams to build, design, and maintain the native components that populate the catalog. What is fundamentally changing, however, is that runtime composition is handled by the agent. This shifts development work from screen-by-screen implementation to component libraries and AI prompt architecture.
From a security perspective, A2UI solves a central problem of previous approaches: A2UI is explicitly designed to minimize the classic risks of AI hallucinations. Since the AI selects exclusively from a pre-registered, pre-coded catalog controlled by the host application, it cannot physically “invent” a non-functional button or generate an erroneous data table. The client retains complete execution and security control.
What does this mean in concrete terms for projects?
For Flutter teams, this opens up immediate areas of action. First: The widget library becomes a strategic asset. The catalog—that is, the collection of `CatalogItems`—defines the set of widgets that the AI is permitted to use. Each `CatalogItem` specifies a name, data schema, and a builder function for rendering the Flutter widget. Anyone investing today in cleanly abstracted, configurable widget architectures is thereby building the direct input interface for future AI agents.
Second, the stack places new demands on testing: QA teams face a new criterion. Checking static screens becomes less central when the screen generates itself at runtime. Testers don’t need to write guardrails for accessibility standards or brand guidelines—the frontend client naturally inherits these from the native styling layer. Instead, QA must test state synchronization, edge cases in component mapping, and the agent’s logical accuracy.
Third, the ecosystem is already making its way into production: Very Good Ventures—a Flutter and GenUI consulting firm trusted by Toyota and GEICO—has developed a Life Goal Simulator where users hand control over to Gemini, which then generates a native-looking UI in real time from a curated catalog of widgets such as sliders, bar charts, and multi-selects.
Assessment
A2UI v0.9 is not a research project—Google is already running A2UI internally in production systems such as Opal, Gemini Enterprise, and the Flutter GenUI SDK, which demonstrates enterprise-ready maturity. Flutter teams that are not yet developing a strategy for generative UI risk having to reactively catch up in two to three years. The question is not whether agentic interfaces are coming—but which companies will have their widget catalog and prompt architecture ready for production in time. For us as Flutter specialists at Portalworks, it’s clear: Every new project should include a GenUI compatibility strategy starting now.
