Last week, Google released version 0.9 of the A2UI protocol – bringing within reach a development that will fundamentally change the foundation of mobile app development: Generative UI allows AI agents to generate tailor-made interface widgets in real time that adapt the interface state to the individual user interaction. The goal behind this is clear: moving from demo scenarios to production readiness. A2UI v0.9 is Google's answer to this – a framework-agnostic standard for declaring UI intent. Flutter plays a central role in this ecosystem.
What 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 intent of the UI. The client application then renders this description with its own native component library – be it Flutter, Angular, or Lit. This approach ensures that agent-rendered UIs are as safe 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 with Gemini or other LLMs – in line with your own brand guidelines and the existing widget catalog.
Technically, the interplay works via three core components: a `SurfaceController`, which manages the widget catalog and applies UI updates, an `A2uiTransportAdapter`, which parses the raw LLM response streams, and a `Conversation` object, which orchestrates the entire interaction cycle. User interactions – clicks, text input – update a client-side data model, which is sent back to the AI as context for the next conversation step. Widgets rebuild automatically when the bound data in the model changes.
The decisive 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. Clean in theory. In practice, LLMs repeatedly broke on complex nested structures at scale. v0.9 reverses this approach: the schema and usage examples go 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 real 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 are not 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 generate rich experiences dynamically.
Dynamic rendering does not mean the end of frontend engineering. Companies still need dedicated engineering teams to build, design, and maintain the native components that populate the catalog. What does change fundamentally, however: composition at runtime lies with the agent. This shifts development work from screen-by-screen implementation toward the component library and AI prompt architecture.
In terms of security, 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 physically cannot “invent” a non-functional button or generate a faulty data table. The client retains full execution and security control.
What does this mean concretely for projects?
For Flutter teams, there are immediate fields of action. First: the widget library becomes a strategic asset. The catalog – i.e., the collection of `CatalogItems` – defines the set of widgets the AI is allowed to use. Each `CatalogItem` specifies a name, a data schema, and a builder function for rendering the Flutter widget. Anyone who invests in cleanly abstracted, configurable widget architectures today is 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 do not have 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 logical accuracy of the agent.
Third, the ecosystem is already being used in production: Very Good Ventures – a Flutter and GenUI consultancy trusted by Toyota and GEICO – has developed a Life Goal Simulator in which users hand control to Gemini, which then generates a native-feeling 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 already runs A2UI internally in production systems such as Opal, Gemini Enterprise, and the Flutter GenUI SDK, which demonstrates enterprise-grade maturity. Flutter teams that do not yet develop a strategy for generative UI today risk having to catch up reactively 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 production-ready in time. For us as Flutter specialists at Portalworks, it is clear: every new project should include a GenUI compatibility strategy from now on.
