Google Unveils A2UI Protocol to Replace AI Chat Text With Live App UI

A2UI: Build Dynamic Apps with Generative UI With Google Cloud — Ai4

Ai4

Adopting a declarative component standard over raw executable code allows AI models to render secure, interactive interfaces natively across platforms without security risks.

AI-assisted summary of A2UI: Build Dynamic Apps with Generative UI With Google Cloud — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 14, 2026, this presentation features Google Cloud and Flutter developer relations engineers and advocates Khanh Nguyen, Terrence Ryan, and Christina Zhu. According to the description, the session focuses on building dynamic, expressive, and personalized user interfaces powered by AI agents using Flutter's GenUI and the A2UI protocol.

## TL;DR The presentation introduces Generative UI (GenUI) and the open-source A2UI protocol to resolve the interaction bottlenecks caused by dense, text-only AI agent responses. Positioned as a secure declarative middle ground between risky raw code generation and rigid static templates, A2UI enables models to describe UI structures as JSON blueprints mapped directly to native design systems. Khanh Nguyen details the technical mechanics of the Flutter GenUI SDK—including component catalogs, reactive state management, transport adapters, and latency mitigation strategies like progressive streaming. The speakers also showcase enterprise implementations like NotebookLM and the Google Gemini app, demonstrating how Flutter's rendering engine and Add-to-App capabilities deliver portable GenUI experiences across mobile, web, and desktop.

## Atmosphere & style The presentation is energetic, pragmatic, and forward-looking, balancing visionary AI interaction design with concrete software engineering patterns. The speakers maintain an engaging and collaborative dynamic, enlivened by relatable critiques of 15-year-old chat paradigms and playful stage moments, such as faking a UI buffering glitch to tackle latency. It feels like an authoritative yet accessible developer deep-dive that equips builders with actionable tools to move past text-box chatbots into dynamic, self-molding user interfaces.

## Key takeaways - [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) Generative UI (GenUI) bridges the interaction gap of traditional text-only AI by replacing static text walls and markdown tables with interactive, actionable native components. - [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) Declarative GenUI represents a balanced architectural middle ground between high-risk dynamic code execution (HTML/JS) and rigid, hardcoded static screens. - [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) A2UI is an open-source, transport-agnostic protocol that enables AI models to describe user interfaces as declarative JSON rather than executable code. - [05:37](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=337s) A2UI ensures client security, cross-platform portability, and strict theming control by delegating visual styling and component execution entirely to the host application's design system. - [07:27](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=447s) The GenUI client-side SDK manages core runtime plumbing, including message transport, surface controllers, reactive state management with two-way data binding, and component registries. - [10:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=618s) Developers supply pre-approved component catalogs to the agent as modular building blocks, keeping LLM outputs bounded and preventing arbitrary layout breakage. - [11:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=678s) Client state management tracks lightweight surface IDs during component lifecycles (`surfaceAdded` and `surfaceRemoved`), with automatic schema validation catching malformed LLM responses. - [13:34](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=814s) Model generation latency in GenUI can be addressed using progressive streaming, layout caching for repeated views, and providing higher-level layout templates instead of atomic primitives. - [15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) Flutter's Add-to-App capability allows engineering teams to embed shared, high-performance GenUI modules directly into existing native Android, iOS, and web codebases. - [18:05](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=1085s) Pairing standardized A2UI JSON payloads with multi-platform rendering engines transforms conversational agents into dynamic, self-molding user interfaces deployed anywhere from a single codebase.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=4s) Introduction and the Generative UI Vision

Christina Zhu, a developer advocate at Google Cloud AI, and Khanh Nguyen, a developer relations engineer on Google's Dart and Flutter team, open the presentation to introduce Generative UI (GenUI) and the A2UI protocol. They outline how GenUI transforms interactions between users and AI agents by moving beyond traditional text-only interfaces toward dynamic, expressive, and tailored user experiences. The session sets up a comprehensive look at how A2UI and its client-side renderers streamline GenUI application development, culminating in real code examples demonstrating practical integration.

---

[00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) The Interaction Gap: Why Walls of Text Fail Complex Tasks

Christina challenges the audience to consider the current state of interacting with AI agents, such as planning a trip or comparing laptop specifications before making a purchase. In almost every case, the agent returns a "giant wall of text" or, at best, a static markdown table. While the model handles the analytical thinking, the user is left doing all the manual labor: reading paragraphs, opening new tabs, and executing actions elsewhere. Because users cannot click on a markdown table to book a flight or drag a price slider embedded in a paragraph, the workflow remains fragmented. Christina notes that in 2026, talking to hyper-capable models through interfaces that resemble "a chat app from 15 years ago" represents a significant interaction bottleneck.

While plain text is well-suited for drafting emails, summarizing documents, or brainstorming, it breaks down when interacting with complex, actionable data. Human cognition relies heavily on spatial processing, visual hierarchy, and interactive affordances such as buttons, toggles, and date pickers. If a chatbot recommends five restaurants, a user does not want a dense paragraph; they need five distinct visual info cards to compare options at a glance, complete with direct reservation buttons. Bridging this gap requires AI agents to communicate with applications in terms of UI components rather than unstructured prose, rendering tangible interfaces directly instead of merely describing options.

---

[03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) The GenUI Spectrum and the A2UI Protocol

Generative UI operates along a architectural spectrum defined by the trade-off between flexibility and security:

1. **Full Dynamic Code Generation:** The agent generates raw executable code (HTML, CSS, and JavaScript). While offering maximum layout flexibility, this approach is extremely dangerous because running unvetted model-generated code exposes client applications to severe security vulnerabilities and prompt injection attacks. 2. **Static Pre-Built Screens:** The agent is restricted to selecting from a rigid, predetermined set of hardcoded screens. While entirely secure and deterministic, it strips away the adaptability and context-aware power that makes generative interfaces useful. 3. **Declarative GenUI (The Balanced Middle):** The agent does not send executable code or merely pick a fixed screen; instead, it outputs a structured, declarative description of the UI composed entirely of trusted, pre-approved components.

```mermaid flowchart LR accTitle: The Generative UI Spectrum subgraph Spectrum["The Generative UI Spectrum"] A["Full Code Gen<br/>(HTML/CSS/JS)<br/>⚠️ High Risk / Max Freedom"] B["Declarative GenUI<br/>(A2UI Protocol)<br/>✅ Safe like data, expressive like code"] C["Static Hardcoded Screens<br/>(Pre-built templates)<br/>🔒 Rigid / Minimal Flexibility"] end A --- B --- C ```

A2UI is an open-source protocol specifically designed to establish this declarative middle ground. Christina emphasizes that A2UI is not a frontend framework or a component library; rather, it is a standardized, shared protocol between agents and clients that enables models to describe UI layouts as pure JSON. Guided by the philosophy of being "safe like data but expressive like code," the agent issues declarative instructions specifying surfaces, component arrangements, and bound datasets without transmitting executable scripts. Furthermore, A2UI is completely transport-agnostic, seamlessly operating over Agent-to-Agent (A2A) protocols, Server-Sent Events (SSE), or WebSockets.

---

[05:37](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=337s) Real-World Implementation and Core Architectural Benefits

Implementing A2UI involves two distinct architectural halves:

```mermaid flowchart TD accTitle: A2UI Communication Pipeline subgraph AgentSide["1. Agent Side"] A["AI Agent"] -->|"A2UI System Prompt"| B["JSON UI Payload<br/>(Declarative Specs)"] end subgraph TransportLayer["Transport Agnostic Layer"] B -->|"SSE / WebSockets / A2A"| C["Client Transporter"] end subgraph ClientSide["2. Client Side"] C --> D["A2UI Renderer"] D --> E["Native App UI<br/>(Design System & Theming)"] end ```

On the agent side, the model is instructed via an A2UI system prompt defining the JSON schema and the component palette it is allowed to construct. On the client side, an A2UI renderer ingests the JSON payload and maps each declared component directly to a native UI widget.

In practice, converting a plain-text conversational agent into a GenUI experience immediately replaces unstructured text walls with structured data views. For instance, querying an inventory agent with "What is in stock?" yields interactive data tables, while inquiring about a specific product returns a dedicated product card embedded with images and action controls.

This architecture delivers three fundamental advantages: - **Security:** The agent only transmits declarative data referencing pre-approved components designed by the developer. If a model hallucinates, the worst-case outcome is an unexpected visual layout rather than malicious code execution on a client device. - **Native Feel and Theming Control:** The renderer renders components utilizing the host application's existing design system, brand styling, and theme tokens. The agent decides structural layout and content, while the developer retains absolute control over appearance. - **Portability:** Because the agent output is a platform-agnostic description of the interface, the identical JSON response can be rendered natively across web, mobile, and desktop environments.

---

[07:27](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=447s) The Client-Side Renderer and Flutter GenUI SDK Architecture

Khanh Nguyen details the responsibilities of the client-side renderer, which parses, validates, and renders the UI structures defined in A2UI messages. While renderers exist across various web and mobile ecosystems, the Flutter team has co-defined the A2UI specification for approximately two years, releasing the official Flutter GenUI SDK on `pub.dev`. Because A2UI is an open standard, the core architectural responsibilities remain consistent regardless of the underlying frontend framework.

```mermaid flowchart TD accTitle: GenUI SDK Core Architecture subgraph CoreEngine["Flutter GenUI SDK"] T["Transporter<br/>(Parse & Validate)"] --> SC["Surface Controller<br/>(Widget Hierarchy)"] T --> DM["Data Model<br/>(Reactive State)"] C["Catalog<br/>(Pre-approved Widgets)"] --> SC DM <-->|"Two-Way Data Binding"| SC Conv["Conversation<br/>(History Helper)"] -.-> T end SC --> S["Surface<br/>(App Viewport / UI Slot)"] ```

The Flutter GenUI SDK abstracts lower-level plumbing so development teams can focus on UI components, design language, and business logic. The SDK manages crucial runtime infrastructure: - **Transporter:** Handles shuttling payloads across transport layers, message parsing, and schema validation. - **Surface Controller:** Tracks component hierarchies, manages active UI elements, and renders layouts into designated app viewports known as *Surfaces*. - **Data Model & Reactive State Management:** Maintains two-way data bindings and event handling. User interactions (such as button presses or form inputs) automatically update the client-side data model, which concurrently sends updated state back to the agent as context for subsequent conversation turns while triggering reactive rebuilds of bound surfaces. - **Catalog:** Houses the registry of allowed components exposed to the AI model. - **Conversation:** An optional helper module that tracks multi-turn conversational history between the client application and the backend agent.

---

[10:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=618s) Composing Interfaces: Component Catalogs and Transport Adapters

Transitioning an existing text-in/text-out chatbot to GenUI begins by supplying a component catalog to the SDK. In Flutter, these components are native widgets. Developers have the option to expose the SDK’s built-in default catalog or supply their own custom design system components, spanning standard inputs and displays such as text fields, sliders, date pickers, action buttons, cards, and data visualization graphs.

By passing this catalog into the GenUI SDK, developers supply the agent with modular "LEGO building blocks" that the model can reference, arrange, and populate with runtime data. This preserves strict boundaries: the A2UI renderer governs dynamic structure and composition, while the host application dictates exact styling, accessibility parameters, and visual branding. Once the component catalog is registered, the next step in implementation is configuring the A2UI transport adapter to establish the communication pipeline with the agent.

[11:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=678s) Implementing the A2UI Transport Adapter and Surface State Management

Connecting a client application to an agent starts with the transport adapter, which handles sending, receiving, and parsing A2UI (Agent-to-UI) messages. Developers implement a custom `onSend` callback to establish a bidirectional A2UI JSON stream to the agent back end. Because the framework is completely agent-agnostic, applications can communicate with any back end or transport protocol, feeding the returned data chunks straight into the transport adapter for processing.

```mermaid flowchart LR accTitle: A2UI Surface Lifecycle and Transport Flow subgraph AgentBackend["Agent Back End"] A["Agent Engine"] end subgraph AdapterLayer["A2UI Adapter Layer"] B["onSend Callback"] C["Transport Adapter & Schema Validator"] end subgraph ClientApp["Flutter Client UI"] D["State Controller"] E["Chat / Surface List Renderer"] end

A <-->|"Bidirectional JSON Stream"| B B -->|"Chunks"| C C -->|"surfaceAdded / surfaceRemoved"| D D -->|"Surface IDs"| E ```

Within the client UI, components requested by the agent can be rendered inside a chat-style list layout. To keep state management lean, the application state only tracks the `surfaceId`—a unique identifier assigned to each specific instance of an A2UI component—while the underlying data model maintains the state and associated payload. The view layer listens for lifecycle events: - **`surfaceAdded`**: Appends the new `surfaceId` to the active list of surfaces to render on-screen. - **`surfaceRemoved`**: Removes the `surfaceId` from the active render hierarchy.

In a live demonstration of a basic GenUI use case, the agent's response arrives not as a flat wall of text, but as structured interactive UI accompanied by descriptive copy. Users can tap interactive buttons directly within the generated component to navigate deeper into the application and continue their workflow. If network disruptions occur or an LLM outputs malformed data, the client does not crash; the SDK performs JSON schema validation under the hood and returns structured errors directly to the controller for standard error handling.

---

[13:34](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=814s) Tackling the Latency Challenge in Generative UI

Addressing performance head-on, the presentation pauses for a humorous bit where the speaker pretends the talk is buffering, joking, "I totally did not just search up a loading progress indicator just for that bit." The central technical hurdle for generative UI is latency. Model generation speed fluctuates based on multiple variables, but handling server latency is a familiar software engineering problem with established solutions that apply directly to GenUI:

- **Progressive Streaming**: Stream incoming components and render them incrementally rather than blocking the UI until the entire payload arrives. - **Layout Caching**: Once an agent synthesizes an effective layout, cache it locally or remotely for instant subsequent loads. The client can maintain an open connection for real-time delta updates without needing to re-generate the full interface on every interaction (e.g., a personalized daily home dashboard). - **Constraining Model Decisions**: Avoid giving the LLM open-ended choices with multiple redundant ways to generate a single screen. Providing opinionated, higher-level layout templates and structured components allows the model to produce consistent UI significantly faster than forcing it to assemble layouts from low-level atomic primitives.

---

[15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) Why Flutter Is the Ideal Engine for GenUI and Add-to-App Integrations

Flutter's core design philosophy is "build for people, not platforms," eliminating the need to rewrite the same generative UI experience across multiple codebases. By bypassing native platform UI wrappers and JavaScript runtime bridges, Flutter's graphics engine, Impeller, draws every single pixel directly to the screen across Android, iOS, macOS, Linux, Windows, and the web with native-level performance.

```mermaid flowchart TD accTitle: Flutter Add-to-App Architecture subgraph HostApps["Native Host Applications"] A["Native iOS App"] B["Native Android App"] C["Web Application"] end subgraph SharedFlutter["Embedded Flutter Module"] D["Add-to-App Bridge"] E["A2UI GenUI Engine & Impeller Canvas"] end

A --> D B --> D C --> D D --> E ```

For teams with existing native applications, Flutter's **Add-to-App** feature allows developers to build rich GenUI modules in Flutter and embed them directly inside existing native codebases. Several major enterprise production examples illustrate this flexibility:

- **NotebookLM (Gemini Notebook)**: When their web application went viral overnight, the team used Flutter to build and launch dedicated iOS and Android mobile apps in just seven months. - **Google Gemini App**: When prototyping the "visual layout" feature back in 2023 to pioneer generative UI, the visual layout protocol was authored in Flutter and embedded into the native iOS, Android, and web versions of the Gemini app using Add-to-App. - **Talabat**: The largest on-demand delivery platform in the MENA region adopted Flutter via Add-to-App before expanding its usage across their core product. - **SoFi**: The US fintech platform serving over 15 million members initially evaluated Flutter through Add-to-App, which eventually led to a full transition and achieved a 60% reduction in their overall codebase.

---

[18:05](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=1085s) The Paradigm Shift: Standardized A2UI Meets Cross-Platform Portability

A2UI fundamentally changes how users interact with AI agents by translating complex backend data into structured JSON blueprints that render as rich, interactive components. Instead of relying solely on text or custom one-off webviews, a single A2UI JSON payload adapts natively to web, mobile, and desktop environments while conforming to the host application's design system.

Coupling the standardized protocol of A2UI with the cross-platform rendering power of Flutter transforms conversational interfaces from simple chat bubbles into "dynamic, self-molding user experiences." Developers write the rendering logic once, deploy it anywhere, and empower their agents to deliver rich, contextual interfaces across any screen.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=4s) Build UI that’s as dynamic, expressive, and personal as the agents that power your experiences using Flutter’s GenUI. — Christina Zhu

> [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) giant wall of text — Christina Zhu

> [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) a chat app from 15 years ago — Christina Zhu

> [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) safe like data but expressive like code — Christina Zhu

> [05:37](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=337s) What is in stock?

> [10:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=618s) LEGO building blocks — Khanh Nguyen

> [13:34](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=814s) I totally did not just search up a loading progress indicator just for that bit. — Khanh Nguyen

> [15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) build for people, not platforms — Khanh Nguyen

> [15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) visual layout — Khanh Nguyen

> [18:05](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=1085s) dynamic, self-molding user experiences

## Mentioned Khanh Nguyen, Terrence Ryan, Christina Zhu, Google Cloud, Google Cloud AI, Ai4, Dart, Flutter, A2UI, Generative UI (GenUI), Flutter GenUI SDK, pub.dev, Impeller, NotebookLM, Google Gemini, Talabat, SoFi

## Video description Khanh Nguyen - Developer Relations Engineer, Google Cloud Terrence Ryan - Developer Relations Engineer, Google Cloud Christina Zhu - Developer Advocate, Google Cloud

Build UI that’s as dynamic, expressive, and personal as the agents that power your experiences using Flutter’s GenUI.

[Source](https://www.youtube.com/watch?v=CVx1a-5fPoA)

中文简报

谷歌推出 A2UI 协议，以实时应用 UI 替代 AI 对话文本 采用声明式组件标准而非原始可执行代码，使 AI 模型能够在无安全风险的情况下跨平台原生渲染安全、可交互的界面。 本次演讲介绍了生成式 UI（GenUI）及开源 A2UI 协议，旨在解决密集纯文本 AI Agent 回复带来的交互瓶颈。作为高风险原始代码生成与僵化静态模板之间的安全声明式折中方案，A2UI 使模型能够将 UI 结构描述为直接映射到原生设计系统的 JSON 蓝图。Khanh Nguyen 详细阐述了 Flutter GenUI SDK 的技术机制，包括组件目录、响应式状态管理、传输适配器以及渐进式流式传输等延迟缓解策略。演讲者还展示了 NotebookLM 和 Google Gemini 应用等企业级落地案例，展现了 Flutter 渲染引擎与 Add-to-App 能力如何在移动端、Web 端和桌面端交付高可移植性的 GenUI 体验。 生成式 UI（GenUI）旨在弥补传统纯文本 AI 的交互短板，通过交互式的原生组件取代静态长文本与 Markdown 表格，让用户可以直接在界面中执行操作。 (0:46) 声明式 GenUI 在高风险的动态代码执行（HTML/JS）与僵化的硬编码静态页面之间取得了平衡；作为开源标准的 A2UI 协议允许模型以纯 JSON 蓝图描述界面，兼顾安全性与跨平台通用性。 (3:09) 客户端渲染器通过预先批准的组件目录（Catalog）与双向数据绑定确保安全呈现与状态同步，宿主应用完全掌管设计系统与样式，且通过 Schema 校验自动拦截异常输出。 (7:27) 针对大模型生成延迟问题，可以通过渐进式流式渲染、布局缓存以及提供更高层级的布局模板来优化渲染速度与交互体验。 (13:34) 结合 Flutter 的跨平台底层渲染与 Add-to-App 嵌入能力，A2UI 统一协议可原生跑通 iOS、Android 及 Web 端，NotebookLM 与 Google Gemini 等产品已在生产环境中验证该架构。 (15:24)

Reading summary

Christina Zhu and Khanh Nguyen argue that the interaction bottleneck in conversational AI can be resolved through Generative UI (GenUI) powered by the open-source A2UI protocol, which lets agents output safe, declarative JSON specifications instead of raw executable code or flat text. The Interaction Bottleneck of Text-Only Interfaces (0:46) Zhu challenges the ongoing reliance on plain text or static markdown tables when handling complex, actionable tasks like comparing laptop specifications or booking travel. While large language models perform analytical reasoning, unstructured paragraphs force users to manually read text, open separate tabs, and execute tasks elsewhere. In her view, communicating with advanced models through interfaces resembling 15-year-old chat applications breaks user cognition, which relies on visual hierarchy, spatial processing, and interactive affordances such as buttons and sliders. The A2UI Protocol's Declarative Middle Ground (3:09) To balance adaptability with security, A2UI establishes a declarative middle ground along the GenUI architecture spectrum. Unrestricted dynamic code generation (HTML, CSS, JavaScript) offers high flexibility but introduces dangerous client security vulnerabilities and prompt injection risks; conversely, static pre-built screens eliminate contextual adaptation. A2UI addresses this by allowing the agent to emit pure JSON layouts built exclusively from pre-approved component palettes. This design treats UI as safe data while remaining expressive like code, and functions agnostically across Agent-to-Agent (A2A), Server-Sent Events (SSE), or WebSocket transport layers. On the client side, renderers ingest the JSON payload and map components directly to native platform widgets. Because the host application manages the styling and design tokens, the developer preserves strict brand and visual control while the agent directs only structural composition. Furthermore, hallucinated responses result at worst in unexpected component layouts rather than remote code execution. Client Architecture and State Synchronization (7:27) Nguyen outlines the client-side architecture using the Flutter GenUI SDK, which has been co-developed with the A2UI specification for approximately two years. The SDK delegates responsibilities among a transporter, a surface controller, a component catalog, and a reactive data model. The transporter parses chunks and validates JSON schemas, returning structured errors rather than crashing the client if an agent emits malformed data. The architecture relies on reactive two-way data binding. User inputs on rendered components automatically update the client data model, which triggers surface rebuilds and returns the updated state to the agent as context for subsequent turns. In the view layer, state management tracks unique component instances via surface IDs, dynamically listening for surface addition and removal events inside application slots. Mitigating GenUI Latency and Multiplatform Deployment (13:34) Performance latency remains a major technical obstacle for dynamic GenUI, but Nguyen identifies three software patterns to address it: streaming components progressively rather than waiting for entire payloads, caching stable layouts for subsequent loads, and restricting model choices to high-level, opinionated layout templates rather than low-level atomic primitives. For cross-platform deployment, the presenters advocate Flutter's Impeller engine, which renders directly to canvas without native wrappers across mobile, desktop, and web. Through Flutter's Add-to-App bridge, teams can embed GenUI modules into existing native applications without full rewrites. Enterprise examples include Google Gemini embedding visual layout protocols across iOS, Android, and web; NotebookLM launching mobile apps in seven months; and SoFi cutting its codebase by 60% after evaluating Flutter via Add-to-App. By combining declarative JSON schemas under the A2UI protocol with cross-platform rendering frameworks, developers can move conversational agents beyond text bubbles into adaptive, native interfaces. However, achieving smooth performance depends heavily on addressing model generation latency through caching, component streaming, and structured schema constraints.

精炼阅读摘要

Google Cloud AI 与 Flutter 团队联合提出开源的 A2UI 声明式交互协议，旨在通过受控的 JSON 蓝图替代传统 AI 对话中的纯文本与 Markdown 静态内容，在保障运行时安全的同时实现跨多端渲染的生成式用户界面（GenUI）。 文本界面的交互瓶颈与生成式UI光谱 (0:46) Google Cloud AI 的 Christina Zhu 指出，当前用户与高能力 AI 智能体交互时，普遍面临模型输出大段文字或静态 Markdown 表格的困境。这类单向纯文本输出要求用户自行阅读、切换应用或手动执行后续动作，无法提供诸如直接点击订票、拖动价格滑块等即时交互功能，形成了显著的交互瓶颈。人类认知高度依赖空间布局、视觉层级与直接交互控件，单纯陈述选项无法支撑复杂的决策任务。 为解决这一问题，生成式 UI 在架构上呈现三种形态的光谱权衡：第一种是全动态代码生成（即直接由智能体生成 HTML、CSS 和 JavaScript），其布局自由度极高，但运行未经审查的模型代码极易引发严重安全漏洞与提示词注入风险；第二种是硬编码的静态预设页面，虽然绝对安全确定，却剥离了上下文自适应能力；第三种则是基于声明式组件的折中方案。开源的 A2UI（Agent-to-UI）协议即属于第三种路径，它不是前端框架或组件库，而是一种智能体与客户端之间的标准化协议，主张“像数据一样安全，像代码一样富有表现力”，仅允许智能体输出描述界面结构和预先核准组件绑定的纯 JSON 数据。 A2UI的双端架构与原生系统集成优势 (5:37) A2UI 系统的工程落地包含智能体侧与客户端渲染器两个核心环节。在智能体侧，系统提示词明确规定了可用的 JSON Schema 以及被允许调用的组件库；在客户端，A2UI 渲染器负责解析该 JSON 载荷，并将声明式指令映射为本地的原生 UI 部件。传输层则保持协议无关性，可灵活采用 Server-Sent Events（SSE）、WebSockets 或 Agent-to-Agent（A2A）协议运行。 根据演讲者的阐述，这种声明式架构具备三大工程收益：一是安全性，智能体仅传输预审组件的声明式数据，即使模型发生幻觉，最差结果也仅是视觉布局异常，而非在客户端设备上执行恶意脚本；二是原生体验与设计体系受控，渲染器完全沿用宿主应用已有的设计系统、品牌样式与主题令牌，开发者依然牢牢掌握最终外观呈现；三是可移植性，同一份与平台无关的 JSON 描述，能够在 Web、移动端和桌面端实现无缝的原生化适配。 客户端SDK架构与双向响应式状态管理 (7:27) Google 的 Dart 与 Flutter 团队开发者关系工程师 Khanh Nguyen 介绍了在 pub.dev 发布的官方 Flutter GenUI SDK。该 SDK 规范了渲染引擎的核心职责，将底层传输与渲染逻辑抽象解耦。其核心模块包括负责载荷解析与 Schema 校验的 Transporter、管理组件树并将其渲染至宿主视口（Surface）的 Surface Controller、维持组件白名单的 Catalog，以及可选的多轮对话历史记录辅助模块 Conversation。 在状态管理方面，SDK 的 Data Model 支持双向数据绑定。用户的操作（如调整表单或点击按钮）会自动更新客户端的数据模型，不仅能触发本地界面的响应式局部重建，还会将新状态同步回传给后端智能体以作为后续轮次的上下文。为了维持精简的状态流，客户端视图层仅需监听 surfaceAdded 与 surfaceRemoved 等生命周期事件以追踪唯一的 surfaceId，底层出现畸变数据时则由内置的 Schema 校验抛出结构化错误，避免应用整体崩溃。 延迟应对策略与Flutter多端嵌入落地 (13:34) 针对生成式 UI 普遍面临的模型生成延迟挑战，演讲提出了三项具体的工程优化手段：一是渐进式流式渲染，组件到达时即时流式绘制，避免界面长时间处于阻塞等待状态；二是布局缓存机制，对已生成的有效界面结构在本地或云端进行缓存，后续仅通过长连接推送数据增量（Delta）更新，适用于个性化仪表盘等场景；三是约束模型的决策空间，提供高阶的布局模板和结构化组件集合，而非让大语言模型从最底层的原子基元组装界面，从而显著减少模型推理决策耗时。 在渲染引擎选型上，Flutter 凭借 Impeller 图形引擎绕过 JavaScript 桥接与平台原生封装，实现跨 Android、iOS、Web 及桌面端的单像素直接绘制。对于已有庞大原生代码库的团队，Flutter 的 Add-to-App 模块化嵌入方案已被多家企业验证：NotebookLM 在短时间内借助 Flutter 推出移动端；Google Gemini App 自 2023 年探索生成式视觉布局时便采用 Flutter 编写并嵌入各端原生容器；中东配送平台 Talabat 与拥有超 1500 万会员的金融科技公司 SoFi 亦通过 Add-to-App 方案逐步接入，其中 SoFi 据称减少了 60% 的总体代码量。 A2UI 协议通过建立跨平台的声明式 JSON 标准，试图在安全性、灵活性与多端一致性之间建立结构化平衡。然而，在实际企业应用中，大模型端到端推理的高延迟依然是制约动态界面流畅度的关键现实阻碍，仍需深度结合流式绘制、模板限制与增量缓存方案加以缓解。

Detailed notes — zh

## Background 该视频由 YouTube 频道 Ai4 于 2026 年 8 月 14 日发布，内容由 Google Cloud 的开发者布道师与工程师团队共同呈现。视频简介指出，本次演讲旨在介绍如何利用 Flutter 的 GenUI，构建与驱动其底层体验的智能体一样动态、富有表现力且个性化的用户界面。 ## TL;DR 演讲直击现有 AI 聊天交互中“文字大瀑布”导致用户必须手动操作的痛点，提出了兼具数据级安全性与代码级表达力的声明式生成式 UI（GenUI）理念。团队详细阐述了开源协议 A2UI 的设计哲学与架构，它通过平台中立的结构化 JSON 让 Agent 与客户端对话，并保持传输层无关。随后，讲者展示了 Flutter GenUI SDK 的客户端渲染机制、组件目录（Catalog）与容错设计，并给出了流式传输、布局缓存等应对延迟的性能策略。结合 NotebookLM、Gemini 等工业级案例，本次分享展示了如何借助 Flutter 的全平台渲染与 Add-to-App 特性，构建出能随用户需求动态自我塑形的下一代交互生态。 ## Atmosphere & style 整场演讲呈现出典型 Google 技术分享的极客严谨与工程落地感，节奏明快且层次分明。两位讲者配合默契，从吐槽“被困在聊天框里做体力活”的幽默自嘲切入，迅速唤起开发者的深切共鸣，随后无缝过渡到底层协议与架构拆解的硬核探讨中。现场氛围兼具前瞻探索的启发性与工业实践的笃定，既有直面大模型延迟痛点时的真实坦诚，又充满了用全新交互范式重构人机协作体验的感染力。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=4s) 生成式 UI（GenUI）旨在打破传统纯文本聊天框的局限，让人机交互迈向可直接操作的原生动态界面。 - [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) 传统 AI 交互的核心痛点在于“文字大瀑布”模式：AI 负责思考，用户却仍被困在将文本手动翻译为操作界面的繁琐体力活中。 - [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) 在 GenUI 技术光谱中，A2UI 选择声明式生成（Declarative Gen UI）路径，遵循“安全如数据，表达力如代码”的设计哲学，杜绝客户端任意代码执行风险。 - [05:41](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=341s) A2UI 协议具备三大核心价值：基于受信任组件的数据级安全性、遵循宿主应用设计系统的原生质感，以及跨 Web/移动/桌面的可移植性。 - [07:27](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=447s) Flutter GenUI SDK 全面接管了底层消息解析、校验与状态流转，支持双向数据绑定与上下文回传的响应式 UI 范式。 - [10:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=618s) 通过 Component Catalog 注册白名单组件，实现了 Agent 仅负责界面结构排布、前端应用牢牢掌控视觉样式与主题规范的权责分离。 - [11:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=678s) 传输适配器配合严格的 Schema 校验机制，不仅使通信与后端框架解耦，还能在 LLM 输出异常或网络波动时实现前端优雅降级。 - [13:34](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=814s) 应对 GenUI 延迟挑战的三大优化策略为：流式渐进式渲染、布局模板缓存，以及通过高级布局收敛模型的微观决策范围。 - [15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) Flutter 凭借 Impeller 渲染引擎与 Add-to-App 渐进式集成机制，已被成功验证并应用于 NotebookLM 和 Google Gemini 等工业级产品。 - [18:05](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=1085s) A2UI 与跨端渲染能力的结合推动了人机交互范式转变，使 AI 应用能够根据用户意图与上下文“自我塑形”，实现自适应的跨终端智能体验。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=4s) 什么是生成式 UI（GenUI）与本次演讲概述 来自 Google Cloud AI 团队的开发者布道师（Developer Advocate）Christina Zhu 与 Google Dart 和 Flutter 团队的开发者关系工程师（Developer Relations Engineer）Khanh Nguyen 共同开启了这场关于生成式用户界面（Generative UI，简称 GenUI）的技术分享。随着大语言模型与智能体技术的爆发，如何让人机交互超越传统的聊天框，成为下一代应用开发的核心命题。 两位讲师明确了本次分享的三个核心目标：首先，深入剖析 GenUI 的定义及其如何颠覆传统用户与 Agent 的交互模式；其次，详细拆解开放协议 A2UI 及其跨平台渲染器（Renderers）如何为开发者提供一种安全、标准且流线化的构建范式；最后，通过端到端的真实代码实操，展示如何借助 Flutter 的 GenUI SDK 将这些理论落地为生动可交互的动态应用。 - **核心主题**：GenUI 的定义、A2UI 协议架构、Flutter GenUI SDK 实践与代码演示。 - **讲师阵容**：Christina Zhu（Google Cloud AI）与 Khanh Nguyen（Dart & Flutter 团队）。 --- ### [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) 现有 AI 交互的痛点：从“文字大瀑布”到真正的操作界面 Christina 引导现场观众回想最近一次使用 AI Agent 的经历：无论是让模型规划旅行路线，还是在购买前对比两款笔记本电脑的参数，用户最终收到的几乎总是“一整面巨大的文字大瀑布（giant wall of text）”，运气好一点时可能还会夹杂一张格式工整的 Markdown 表格。但现实往往十分尴尬——面对这堆详尽的文字，用户只能默默阅读，然后切出界面自己去手动完成所有操作。 ```mermaid flowchart TD accTitle: 传统 AI 聊天交互与 GenUI 交互对比 subgraph Traditional["传统 Chat 交互模式（割裂）"] A["用户自然语言提问"] --> B["AI 思考并输出长文本 / Markdown 表格"] B --> C["用户手动阅读文字"] C --> D["用户切换至第三方应用手动点击预订/筛选"] end subgraph GenUI["GenUI 交互模式（无缝操作）"] E["用户提出复杂需求"] --> F["Agent 输出结构化 UI 描述（A2UI JSON）"] F --> G["客户端原生渲染交互卡片与控件"] G --> H["用户直接在卡片上点击预订、拖动滑块"] end ``` Christina 一针见血地指出："模型完成了所有的思考，但我仍然是那个做所有体力活的人（The model did the thinking, but I am still the one that's doing all the manual work.）"——用户无法直接点击 Markdown 表格去订机票，也不能在一段描述文字里拖动滑块按价格筛选。在技术高度成熟的今天，人类依然像十五年前使用早期聊天软件那样与顶尖大模型沟通，这本身就极不协调。文本在起草邮件、提炼长文摘要或头脑风暴时表现优异，但在处理复杂结构化数据时却是极为低效的载体。人类天生具备空间信息处理能力，依赖视觉层级来抓取关键要点，需要的是可点击的按钮、开关和日期选择器： > "聊天机器人可以在一段文字里给你描述五家餐厅，但你真正想要的是五张能一眼看清对比的信息卡片，并且每张卡片上都带有一个直接预订座位的按钮。" 这正是当前 AI 体验的核心鸿沟：AI 负责思考，用户却被困在“将文本手动翻译为外部点击操作”的繁琐流程中。要彻底弥合这一差距，Agent 必须学会直接使用“UI 语言”与前端应用对话，告诉应用“向用户展示这些组件”，而应用端则负责安全、原生地区渲染这些组件。 --- ### [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) 生成式 UI 的光谱与 A2UI 协议的设计哲学 为了精准定义 GenUI 的技术边界，Christina 提出了“生成式 UI 光谱（Spectrum of Generative UI）”理论。开发者在光谱上选择的位置，直接决定了系统在**灵活性**与**安全性**之间的权衡取舍： | 方案模式 | 运行机制 | 优势 | 潜在缺陷 / 安全风险 | |:--- |:--- |:--- |:--- | | **完全代码生成 (Code Generation)** | Agent 直接生成原生 HTML/CSS/JavaScript 代码并在客户端执行 | 灵活性极高，不受任何预设 UI 限制 | 极其危险。面临 Prompt 注入漏洞，可能在用户设备上运行恶意可执行代码 | | **静态界面选择 (Static Pre-built)** | Agent 只能从开发者预先写死的一组固定屏幕/页面中挑选触发 | 绝对安全，行为完全确定 | 几乎丧失了“生成式”的本质灵活性，难以应对长尾、动态的交互诉求 | | **声明式生成 (Declarative Gen UI)** | Agent 仅输出结构化的组件组合描述（JSON），客户端映射到受信任的原生组件 | 兼具数据级的安全性与代码级的表达力（确定性渲染，杜绝代码执行） | 需要客户端配备对应的协议渲染器（Renderer）并预设组件目录 | ```mermaid flowchart LR accTitle: 生成式 UI 的光谱分布 A["完全代码生成<br/>(生成 HTML/JS/CSS)<br/>⚠️ 灵活但存在安全风险"] <--> B["声明式 Gen UI (A2UI)<br/>(JSON 描述 + 预置信任组件)<br/>✅ 安全、灵活、原生"] B <--> C["静态界面选择<br/>(仅挑选预置屏幕)<br/>🔒 安全但缺乏动态表达力"] ``` 位于中间地带的正是**声明式生成 UI（Declarative Gen UI）**，它既不运行不可信代码，也不死板地限制在几张固定页面，而是由 Agent 基于开发者信任的组件库输出界面声明，应用负责受控渲染。 A2UI 协议正是为这一中间地带量身打造的标准协议。Christina 特别强调，**A2UI 既不是一个 UI 框架，也不是一个前端开发库，而是 Agent 与客户端之间达成共识的“通用语言”（Shared Language）**。A2UI 的设计哲学被团队精辟地概括为：**"安全如数据，表达力如代码（Safe like data but expressive like code）"**。Agent 发出的指令仅包含创建界面、指定组件以及传递背后业务数据的 JSON 载荷，不含任何可执行脚本。此外，A2UI 具备完全的**传输层无关性（Transport Agnostic）**，同一份 A2UI 负载可以通过 A2A、Server-Sent Events（SSE）或 WebSocket 无缝流转，且全套规范完全开源。 --- ### [05:41](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=341s) A2UI 的实际构建与三大核心价值 在实际落地过程中，构建一套 A2UI 系统仅需打通两个核心环节： 1. **Agent 端**：通过向大模型注入 A2UI 系统提示词（System Prompt），教会模型“使用 A2UI 语言进行表达”，严格约束其输出结构化的组件声明与数据绑定。 2. **Client 端**：在前端集成 A2UI 渲染器，负责解析收到的 JSON 消息，并将其动态映射为本地预置的原生 UI 控件（Native Widgets）。 Christina 分享了自己构建商店 Agent 的实战体会：原本输出枯燥纯文本或纯 JSON 的 Agent，在接入 A2UI System Prompt 并搭配前端渲染器后，当被问及“有哪些库存？”时，界面立刻自动渲染为清晰的商品数据表格；当进一步询问某款具体商品时，模型则返回一张图文并茂的产品卡片，并内置了商品大图与操作入口。这种架构带来了三大无可比拟的核心价值： - **安全性（Security）**：Agent 永远只传输映射到预审核组件的数据。模型即使失控（Hallucination / Off the rails），最坏的结果也只是渲染出一个布局略显奇怪的界面，绝不可能在用户设备上执行任意恶意代码。 - **原生质感（Native Look & Feel）**：渲染器完全调用宿主应用的设计系统（Design System）、品牌主题与原生组件。Agent 决定“展示什么内容与结构”，而开发者牢牢掌控“具体的视觉与样式”。 - **跨平台可移植性（Portability）**：由于传输的仅是平台中立的 UI 描述，相同的 Agent 响应可以无缝在 Web、iOS、Android 和桌面端（Desktop）上以各平台最原生的高性能方式渲染呈现。 --- ### [07:27](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=447s) Flutter GenUI SDK 架构与客户端渲染实现 随后，来自 Flutter 团队的 Khanh Nguyen 深入剖析了客户端如何高保真地渲染 A2UI 消息。客户端渲染器的核心职责是完成协议消息的**解析（Parsing）、校验（Validation）与最终渲染（Rendering）**。作为 A2UI 协议长达两年的核心共建团队，Flutter 将其渲染实现封装在官方发布的 `Flutter GenUI SDK` 中（已上线 Flutter 官方包管理平台 pub.dev）。Khanh 补充说明，即使开发者使用的是 React、Vue 或其他原生移动端技术栈，A2UI 的核心协议规范与渲染职责也是完全通用一致的。 ```mermaid flowchart TD accTitle: Flutter GenUI SDK 内部核心架构 subgraph Backend["Agent / 后端服务"] Agent["AI Agent (A2UI Prompt)"] end subgraph Client["Flutter GenUI SDK 客户端架构"] Transporter["Transporter (传输/解析/消息校验)"] Catalog["Component Catalog (可用组件/Widget 白名单)"] Controller["SurfaceController (界面生命周期与组件管理)"] DataModel["Data Model (响应式状态与数据流)"] Surface["Surface (指定渲染区域 / 交互画布)"] Conversation["Conversation (可选：会话上下文管理器)"] end Agent <-->|"A2UI JSON (SSE/WebSocket)"| Transporter Transporter --> Controller Catalog --> Controller Controller <--> DataModel Controller --> Surface DataModel -.->|"状态变更回传上下文"| Transporter ``` Flutter GenUI SDK 采取了“封装机制（How），让开发者专注于业务价值（What）”的设计理念，全面接管了状态追踪、事件绑定等底层基建： - **双向数据绑定与上下文回传**：SDK 能够自动捕获用户的界面交互（例如按钮点击、文本输入框输入等），就地更新客户端的 Data Model，并将其作为最新上下文回传给 AI Agent，支撑下一轮的多轮对话。 - **响应式 UI 范式（Reactive UI Paradigm）**：界面中的 Surface 组件与 GenUI Data Model 深度绑定。一旦数据模型发生变动，绑定的 UI 视图会自动完成响应式局部重构，无需开发者手动编写繁琐的 DOM 或 Widget 刷新逻辑。 --- ### [10:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=618s) 从纯文本聊天迈向组件化：Catalog 与数据交互闭环 Khanh 演示了如何将一个传统“文本进、文本出（Text in, text out）”的简陋聊天界面改造成支持 GenUI 的全功能动态应用。改造的第一步是向 SDK 注入**组件目录（Component Catalog）**。 在 Flutter 语境下，这些组件即为原生 Widgets。开发者既可以直接沿用 SDK 开箱即用的默认组件库，也可以将自身业务的组件库（文本框、滑块 Slider、日期选择器 Date Picker、操作按钮、卡片 Card、图表 Graphs 等）注册进 Catalog。向 SDK 提供 Catalog 的过程，就如同“赋予 AI 一套乐高积木块（LEGO building blocks）”，Agent 可以在生成的描述中自由引用、嵌套和组合这些积木，而组件的具体视觉风格与主题规范始终牢牢掌握在前端应用手中。 - **结构与样式的权责分离**：A2UI 协议与 Agent 仅负责决定界面结构的组织排布，组件的渲染样式与交互行为始终由前端应用的 Design System 严格控制。 - **适配器接入**：完成组件目录配置后，接下来只需实例化 A2UI 传输适配器（Transport Adapter），即可建立客户端与 Agent 之间安全、流式的结构化通信通道。 ### [11:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=678s) A2UI 消息传输、组件渲染与容错机制 在客户端集成中，传输适配器（Transport Adapter）扮演着核心纽带角色，专门负责发送、接收以及解析来自 Agent 的 A2UI 消息。开发者只需实现自定义的 `onSend` 回调函数，即可将应用程序无缝接入后端的智能体（Agent），并在双向 A2UI JSON 流上进行实时监听。这套机制完全与 Agent 解耦（Agent-agnostic），开发者无论采用何种通信传输方式、后端框架或 Agent 架构，都可以直接把 Agent 返回的数据块（chunks）交由传输适配器统一处理。 在界面呈现层面，应用会根据 Agent 的指令动态渲染对应组件（例如以聊天式列表布局展示）。应用程序的状态层仅需追踪每个 A2UI 组件实例所独有的 `surfaceId`，由底层数据模型维护相应的状态和关联数据。整个渲染生命周期依托于事件监听机制： - 收到 `surfaceAdded` 事件时：将该 `surfaceId` 压入当前聊天窗口需要渲染的界面列表中； - 收到 `surfaceRemoved` 事件时：将对应的 `surfaceId` 从待渲染列表中剔除。 这种模式彻底告别了传统大语言模型输出的单一枯燥“文本墙”（wall of text），取而代之的是图文并茂、高度结构化的交互式 UI。用户可以直接点击界面中的操作按钮，无缝跳转至更深层次的应用交互页面。 针对网络抖动或 LLM 输出偶发不稳定的情况，系统设计了严密的容错机制。A2UI SDK 内置了严格的 JSON 解析与模式校验（Schema Validation）。一旦 Agent 返回了非标准 A2UI 消息或纯文本异常，SDK 会第一时间向控制器抛出结构化错误，使前端能够像处理常规应用异常一样优雅降级，而不会发生界面崩溃或用户流失。 ```mermaid flowchart LR accTitle: A2UI 消息与组件渲染流 subgraph Backend["Agent 后端"] A["Agent 生成数据块"] end subgraph ClientSDK["客户端 A2UI SDK"] B["Transport Adapter\nonSend 回调"] C{"JSON 解析与\nSchema 校验"} D["错误处理控制器"] end subgraph UIState["Flutter 视图层"] E["Surface 状态管理\n(追踪 surfaceId)"] F["动态 UI 组件渲染\n(Chat 列表 / 交互视图)"] end A -->|"双向 JSON 流"| B B --> C C -->|"校验失败"| D C -->|"surfaceAdded / surfaceRemoved"| E E --> F ``` --- ### [13:34](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=814s) 应对延迟痛点：生成式 UI 的三大性能优化策略 在谈及生成式 UI（GenUI）时，讲者幽默地通过模拟“界面正在思考中”的加载菊花图开场，直面业内最关心的核心痛点——“房间里的大象”即延迟问题（Latency）。无论大模型迭代速度有多快，实时动态生成定制化界面的耗时始终受制于模型推理与网络环境。然而，处理服务端延迟是软件工程长期面对的课题，经典的三大优化方案在 GenUI 架构中依然行之有效： 1. **流式传输与渐进式渲染（Streaming & Progressive Rendering）**：无需等待整个完整 UI 结构的 JSON 全部生成完毕，而是以流式方式持续接收组件片段并逐步上屏渲染。 2. **布局缓存（Caching）**：一旦 Agent 为用户生成了特定的 UI 布局，便将其缓存以供后续秒级加载。例如应用首页仪表盘，仅需每天根据用户最新的当日状态和数据重新生成一次，期间依旧可以保持与 Agent 的连接以推送实时组件更新，避免“为了生成而每次全量重新生成”。 3. **收敛模型决策范围（Narrow the Scope of Decisions）**：避免给模型提供五花八门的底层拼装选项，而是提供高度结构化、预定义的高级布局模板（Opinionated Layout Templates）。减少模型必须做出的微观决策数量，不仅能显著降低 Token 消耗与生成耗时，更能确保生成界面的风格一致性。 --- ### [15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) 为什么选择 Flutter：全平台渲染与 Add-to-App 渐进集成 Flutter 成为构建生成式 UI 的理想载体，源于其团队始终坚持的开发哲学——“为用户而构建，而非为平台而构建”（"Build for people, not platforms"），开发者无需为实现同一套 GenUI 功能而在不同平台重复开发三遍代码。Flutter 能够覆盖几乎所有具备像素渲染能力的屏幕，包括 Android、iOS、Linux、macOS 以及 Windows。它绕过了传统跨平台框架所依赖的原生 UI 控件与运行时桥接层（Runtime Bridges），通过自研的底层图形渲染引擎 Impeller 逐像素直接绘制到屏幕上，从而实现了真正的原生级高性能。 在实际工业级应用与落地实践中，演讲列举了多个极具代表性的企业案例： - **NotebookLM（现更名为 Gemini Notebook）**：Web 版应用爆火之后，团队急需在最短时间内上线移动端。他们选用 Flutter 进行全栈开发，仅用时 7 个月便完成了 iOS 与 Android 双端移动应用的构建并成功发布。 - **Add-to-App 渐进式集成机制**：对于拥有庞大原生代码库的现有应用，开发者无需重写整个项目，可借助 Add-to-App 特性单独将 Flutter 构建的 GenUI 体验模块化嵌入到原生应用中。 - **Google Gemini App（Visual Layout）**：早在 2023 年，Gemini 团队在原型探索 GenUI 交互形态时，其底层的“视觉布局协议”（Visual Layout Protocol）便是完全基于 Flutter 打造的。尽管 Gemini 客户端主体为原生开发，但最终通过 Add-to-App 将该功能无缝嵌入到了 iOS、Android 和 Web 三大客户端。 - **行业巨头转型案例**：中东及北非（MENA）地区最大的即时配送平台 Talabat，以及拥有超过 1500 万会员的美国金融科技 Super App 平台 SoFi，均最初通过 Add-to-App 评估 Flutter，随后全面转向 Flutter 全职开发；其中 SoFi 成功削减了高达 60% 的代码库体积。 --- ### [18:05](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=1085s) 范式转移：A2UI 与 Flutter 打造自适应交互生态 A2UI 协议从本质上重构了人与 AI Agent 的交互范式。它通过结构化的 JSON 蓝图，将原本晦涩、复杂的后端 Agent 业务数据直观转译为高度丰富、具备原生交互能力的动态 UI 组件，提供了远胜于单纯文字对话的沟通效率。一份统一的 JSON 响应，就能在 Web、移动端和桌面端遵循宿主应用本身的设计系统（Design System）自适应渲染。 这不仅是为研发团队节省了海量的开发工时，更代表着人机交互界面的深远变革。将 A2UI 的标准化协议规范与 Flutter 强大的跨平台底层图形渲染能力相结合，开发者所构建的不再仅仅是一个机械问答的 Chatbot，而是一个能够针对用户需求与场景随时“自我塑形”（Dynamic, self-molding user experience）的智能化动态体验——真正实现“一次编写，让智能体跨越任意终端无处不在”。 ## Notable quotes > [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) The model did the thinking, but I am still the one that's doing all the manual work. — Christina Zhu > [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) 模型完成了所有的思考，但我仍然是那个做所有体力活的人 — Christina Zhu > [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) 一整面巨大的文字大瀑布（giant wall of text） — Christina Zhu > [00:46](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=46s) 聊天机器人可以在一段文字里给你描述五家餐厅，但你真正想要的是五张能一眼看清对比的信息卡片，并且每张卡片上都带有一个直接预订座位的按钮。 — Christina Zhu > [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) A2UI 既不是一个 UI 框架，也不是一个前端开发库，而是 Agent 与客户端之间达成共识的“通用语言”（Shared Language）。 — Christina Zhu > [03:09](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=189s) 安全如数据，表达力如代码（Safe like data but expressive like code） — Christina Zhu > [07:27](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=447s) 封装机制（How），让开发者专注于业务价值（What） — Khanh Nguyen > [10:18](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=618s) 赋予 AI 一套乐高积木块（LEGO building blocks） — Khanh Nguyen > [15:24](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=924s) 为用户而构建，而非为平台而构建（Build for people, not platforms） — Khanh Nguyen > [18:05](https://www.youtube.com/watch?v=CVx1a-5fPoA&t=1085s) 一次编写，让智能体跨越任意终端无处不在 ## Mentioned Christina Zhu, Khanh Nguyen, Terrence Ryan, Google Cloud, Google Cloud AI, Dart, Flutter, Flutter GenUI SDK, A2UI, GenUI (Generative UI), pub.dev, Impeller, NotebookLM (Gemini Notebook), Google Gemini App, Talabat, SoFi, React, Vue, Ai4 ## Video description Khanh Nguyen - Developer Relations Engineer, Google Cloud Terrence Ryan - Developer Relations Engineer, Google Cloud Christina Zhu - Developer Advocate, Google Cloud Build UI that’s as dynamic, expressive, and personal as the agents that power your experiences using Flutter’s GenUI. [Source](https://www.youtube.com/watch?v=CVx1a-5fPoA)

Source quotes

[0:46] Christina Zhu: The model did the thinking, but I am still the one that's doing all the manual work. [0:46] Christina Zhu: 模型完成了所有的思考，但我仍然是那个做所有体力活的人 [0:46] Christina Zhu: 一整面巨大的文字大瀑布（giant wall of text） [0:46] Christina Zhu: 聊天机器人可以在一段文字里给你描述五家餐厅，但你真正想要的是五张能一眼看清对比的信息卡片，并且每张卡片上都带有一个直接预订座位的按钮。 [3:09] Christina Zhu: A2UI 既不是一个 UI 框架，也不是一个前端开发库，而是 Agent 与客户端之间达成共识的“通用语言”（Shared Language）。 [3:09] Christina Zhu: 安全如数据，表达力如代码（Safe like data but expressive like code） [7:27] Khanh Nguyen: 封装机制（How），让开发者专注于业务价值（What） [10:18] Khanh Nguyen: 赋予 AI 一套乐高积木块（LEGO building blocks） [15:24] Khanh Nguyen: 为用户而构建，而非为平台而构建（Build for people, not platforms） [18:05] 一次编写，让智能体跨越任意终端无处不在

Source quotes

[0:04] Christina Zhu: Build UI that’s as dynamic, expressive, and personal as the agents that power your experiences using Flutter’s GenUI. [0:46] Christina Zhu: giant wall of text [0:46] Christina Zhu: a chat app from 15 years ago [3:09] Christina Zhu: safe like data but expressive like code [5:37] What is in stock? [10:18] Khanh Nguyen: LEGO building blocks [13:34] Khanh Nguyen: I totally did not just search up a loading progress indicator just for that bit. [15:24] Khanh Nguyen: build for people, not platforms [15:24] Khanh Nguyen: visual layout [18:05] dynamic, self-molding user experiences

Original transcript

[0:04] Um, my name is Christina. I'm a developer advocate  at Google Cloud AI. Um, and my name is Kan Newen. [0:11] I'm a developer relations engineer on the Dart and  Flutter team at Google. So, in the session today, [0:17] we're excited to talk to y'all about what  GenUI is and why it's going to help us [0:22] build better experiences for user and agent  interactions, along with how ATUI and its renders [0:27] actually help facilitate a more streamlined way  of building these GenUI experiences. And finally, [0:33] towards the end, we're going to run through some  real code so that you'll see how it can actually [0:38] be done. So, with that said, Christina, I'll  leave you to kick us off. Thank you very much. [0:46] All right. So, think about the last time  you asked an AI agent to do something. [0:51] Maybe you asked it to help you plan a trip or  maybe compare a couple laptops before buying one. [0:57] Um, so what did you actually get back?  It's usually a giant wall of text. [1:02] And if you're lucky, maybe you would  get a nice markdown table as well. [1:07] So, with that in mind, what did you do with the  wall of text? So, honestly for me, I just actually [1:14] just read the text and then I just go do the thing  myself. Because, you know, I can't really click on [1:19] a markdown table to book the flight and I can't  drag a slider in a paragraph to filter by price. [1:25] The model did the thinking, but I am still  the one that's doing all the manual work. [1:29] Turning the text into an actual action. I think  in 2026, that is a little strange. We have these [1:35] incredibly capable models, but we're still talking  to them like it's a chat app from 15 years ago. [1:43] So, chat is a great interface for some things. If  I want to draft an email or summarize a document [1:48] or in storm, text is perfect. But text is a pretty  bad interface for interacting with complex data. [1:54] And that's because of how humans work. When we  process information spatially, we rely on visual [2:00] hierarchy to know what matters. And we want to do  something, we reach for real UI buttons, toggles, [2:06] or a date picker. A chatbot can describe five  restaurants to you um in a paragraph, but what you [2:12] actually want is five info cards you can compare  at a glance with a button on each one to book [2:18] a table at the restaurant. That is a completely  different experience, even though the underlying [2:23] information is still the same. So, the gap I care  about is here. The AI does the thinking, but the [2:29] user is stuck doing the heavy lifting, which is  reading the text, then translating it into clicks [2:34] and actions somewhere else. What we really want  is for the AI to hand you something that gives you [2:42] something you can use. Instead of  describing the options, it renders them. [2:48] And for the AI to be useful here, agents need  to talk to apps in terms of UI, not just text. [2:54] The agent needs a way to say, "Show the user  these components." And the app needs a way [2:58] to safely render them. So, the natural  question is, how do we actually do that? [3:03] And that's what generative UI is and  ATUI is. Let me walk you through it. [3:09] So, I want to be precise about what we mean  because generative UI is really a spectrum. [3:14] And where you land on it changes how  we handle flexibility and security. [3:18] On one end, the agent generates all of the  UI code. So, that includes the actual HTML, [3:23] CSS, and JavaScript. This is the most  flexible option and also the scariest [3:28] because now you're running code that a model  wrote. That can be a security issue when it [3:33] comes to things like prompt injection and other  vulnerabilities. On the other end of the spectrum, [3:38] we have an agent that can only pick from a very  fixed set of screens that you already built. [3:43] Very safe because nothing new is ever generated,  but at that point, it's barely generative. [3:48] You've locked it down so hard, you've lost  the flexibility that made this interesting. [3:53] And then there's the middle, which is declarative  gen UI. Because the agent doesn't send code, [3:58] it's just as safe as static UI generation because  they are both deterministic. The agent doesn't [4:04] send code and it doesn't just pick a screen.  It sends a description of the UI built from the [4:08] components that you already trust. And your agent  just writes that. Um and then your app renders it. [4:16] We call this declarative gen UI. The agent gets  real freedom over the layout and the content, [4:21] but it can never run code on your users' devices.  So, A2UI is a protocol built exactly for that [4:29] middle ground. I want to be careful with the  word protocol because A2UI is not a framework [4:35] and it's not a library that you use to build  your app in. It is a shared language between [4:41] agent and clients, an agreed-upon way for an agent  to describe UI as a JSON file. The A2UI team and [4:48] the community have created renderers as well  to display the JSON, but I'll cover that later. [4:54] The way the A2UI team puts it is that you want a  UI that's safe like data but expressive like code, [5:00] and that is a pretty good summary. The agent sends  messages like create this surface, here are the [5:06] components, and here is the data behind them.  None of it is executable. It is still just JSON. [5:12] One thing that I really like about it is that it's  transport agnostic. So, the same A2UI payload can [5:18] travel over A2A, over server-sent events, and over  web sockets. The protocol doesn't care how it gets [5:25] there, and it's open source, so it's completely  free and available use available to use today, [5:30] and it works with any agent on any client that  has a renderer. I actually got to build with [5:37] this recently, and I want to walk you through  what that actually looked like in practice. [5:41] There are really two pieces. So, the first piece  is on the agent side. You teach the model to speak [5:46] A2UI. That prompts the model exactly what it's  allowed to produce. Second, on the client side, [5:53] you have a renderer that reads the JSON and  maps each component to a real native widget. [5:58] I took a plain text agent, I gave it the ATUI  system prompt and put a renderer in front of it. [6:06] Instead of getting a wall of text or a wall  of JSON, I started getting cards and tables. [6:10] For example, if I had a store agent and I asked  it, "What is in stock?" It started giving me back [6:16] tables. When I asked about a specific item that  was in stock, it would come back as a card with [6:21] a product image right inside it. So, it just knew  how to show up as UI now instead of just a massive [6:26] wall of text. Building it this way gets you three  things that matter. First is security. The agent [6:34] only ever sends data mapped to components that you  already pre-approved and designed by yourself. So, [6:40] even if the model goes off the rails, the worst  case is a layout that you don't really recognize, [6:45] not code running on someone's device. Second  is that it feels native. Your renderer uses [6:51] your components, your design system, and  your theme. The agent decides what to show, [6:56] but you keep full control over how it looks.  And third is portability. Because it's just a [7:02] description of the UI, the same agent response  can render on the web, mobile, or on desktop. [7:08] So, the protocol gives us a safe,  portable way for agents to describe UI. [7:13] That The interesting question is how you  render it really well on a real device. [7:18] And that's exactly what Khan is going to show you  with Flutter's Gen UI SDK. So, Khan, over to you. [7:27] Awesome. Thank you, Christina. All right. So,  ATUI relies on a client-side renderer to actually [7:33] finish the job of parsing, validating, and finally  rendering the UI that's described in that message. [7:39] There's ATUI renderers for a wide variety of  web and app development frameworks. Um one of [7:44] them just happens to be Flutter. So, Flutter uh  our team has been a project partner defining the [7:49] ATUI protocol for something like about 2 years  now. And Flutter's ATUI render is a part of the [7:56] Flutter GenUI SDK that is available on pub.dev, uh  Flutter's official package repository. So, keep in [8:04] mind um even if you've never heard of Flutter and  you're not building with Flutter or the Flutter [8:08] GenUI SDK, that's not a problem because ATUI is a  standard protocol. So, the renderer concepts and [8:15] responsibilities will be consistent with the  ATUI spec um regardless of your tech stack. [8:21] So, the and the SDK will encapsulate the how so  that you and your teams can focus on the what. [8:28] So, the goal here is to enable devs to focus on  the important things like the UI components, the [8:33] design language, and the business logic. The SDK  manages the rest including all the infrastructure [8:39] that's required for building GenUI experiences  like keeping track of the components that are [8:44] being rendered uh and the component state. So,  for example, um event handling and data bindings. [8:52] So, the SDK will automatically capture user  interactions, for example, button clicks, [8:56] uh text input, and things like that and update  the client-side data model which then sends the [9:01] state back to your AI as context for the next  turn of the conversation. On the flip side, [9:07] it also ensures a reactive UI paradigm. So,  components, uh surfaces as they're called, [9:13] are automatically rebuilt when the data they  are bound to uh changes in the GenUI data model. [9:21] So, it includes a number of tools and  services that manage the overhead for you, [9:25] um including these on the screen. So, you've  already seen the surface controller for managing [9:29] UI components and the data model uh for storing  and managing data and state. Um there's a few more [9:35] in addition to that, uh the catalog which lets  you define the components that the AI can use, [9:40] uh the transporter for shuttling messages back  and forth and parsing and validating messages. Um [9:46] a surface is the designated spot in your app where  you'd like to display uh your GenUI components, [9:52] and conversation, which is an optional helper  class for keeping track of conversation history [9:58] between your app and your agent. So, together, the  architecture looks a little something like this. [10:05] Um the goal here is that, again, the SDK kind of  manages everything, all the overhead for you with [10:11] building GenUI experiences, so that you don't have  to manage these things uh yourselves. All right. [10:18] So, let's see how it look in practice adding GenUI  to this like standard, you know, chatbot style uh [10:24] AI uh app, right? So, right now, it's just text.  Text in, text out. That's what you have. So, [10:31] we'll start by providing a catalog of components.  Um in Flutter, we call components widgets, um and [10:36] you can use the set of widgets that matches your  design system, or you can use a default component [10:42] catalog that the SDK already provides for you.  Um it can be anything, right? Text, text fields, [10:48] sliders, date picker, buttons, cards, graphs.  You get the point. You provide the components. [10:55] By passing the catalog of components to the SDK,  you're giving the AI LEGO building blocks that [11:00] it can reference and compose while maintaining  complete control of how each component looks. [11:06] So, as Christina mentioned, remember that the  ATUI renderer dictates structure, but not styling, [11:11] because you're still in control of that. Next,  you'll construct the ATUI transport adapter. [11:18] This is responsible for sending, receiving,  and parsing your ATUI messages from the agent. [11:24] And here, you'll implement your own on send  callback. And so, this callback is where you [11:29] connect your app to your agent back end and  listen on a bidirectional ATUI JSON stream. [11:36] This is agent agnostic. You can connect  it to whatever back-end you want, [11:39] right? Talk with any agent you want using whatever  transport method you want, as Christina mentioned. [11:45] Then just give the chunks returned by the  agent to the transport adapter for processing. [11:51] So, somewhere in your app, you're going to  render the components that the agent requested. [11:55] Here we're rendering the components as a chat  style list layout. We're only keeping track of [12:00] the surface ID as part of the app state. It's a  unique ID to that specific instance of the ATUI [12:06] component. So, the data model then just keeps  track of the state and any associated data. [12:13] From there, we're just going to listen for surface  added and surface removed events. This is where [12:17] you define what should happen when the agent sends  an ATUI message to add or remove a component. [12:25] On a surface added event, add the surface ID to  list of surfaces that needs to be rendered to [12:30] the chat window. And on a surface removed event,  remove the surface ID from the list of surfaces [12:35] that is currently being rendered. And so, once  all is said and done, here's kind of like a [12:41] preliminary example of how GenUI would look in the  most simple use case scenario. So, you'll see once [12:48] the response comes back, it'll give you UI and  text instead of just a singular wall of text, [12:55] right there. And so, you can tap on the button and  it will actually lead you to a screen where you [13:03] can further your interaction with the app, right  there. All right, so, LLMs aren't perfect and [13:10] network disruptions can happen. Then what? Does  the entire UI just fall apart and collapse and [13:15] your user quits? Well, no, not quite. So, the SDK  handles parsing the JSON and schema validation. [13:22] So, if your agent returns anything but a proper  ATUI message or plain text, an error gets returned [13:28] to the controller so that you can properly  handle it like any other error in your app. [13:34] Well, let's talk about the elephant in the room  here. Um, just give it a second. It's just It's [13:40] It's thinking. I totally did not just search up a  loading progress indicator just for that bit. Um, [13:47] so the elephant in the room here is latency,  right? Any engineer here is thinking about [13:52] the performance implications of GenUI. Even as  models get better with every single release, [13:57] how fast a model can generate custom UI on  the fly really depends on a number of factors. [14:02] So, how do we build GenUI experiences that have  tolerance and flexibility to adapt to these [14:07] varying loading times? It's not the first time  that we've dealt with server latency, right? AI or [14:13] not. So, many of the same old reliable solutions  still also apply here. For example, streaming. [14:20] Stream in the components and progressively render  them. Don't wait for the entire UI to arrive. [14:26] Caching. Once an agent generates a  layout, cache them for later use. [14:30] This enables UI to load instantly on subsequent  uses. You can still have a connection to the [14:35] agent so that it continues to push real-time  component updates, but just because you can [14:40] generate new UIs doesn't mean that you have to  do it every single time. For example, a home [14:45] dashboard that updates daily taking into account  your user's data and the state for the day. [14:52] And finally, narrow the scope of decisions  that the model actually needs to make [14:56] to produce the UI. Don't give the model  five different ways to produce a single UI. [15:02] Specify just one preferred solution. For example,  provide layout templates, higher-level components [15:07] with structured layouts instead of forcing  the model to construct entirely new UIs [15:12] from lower-level building blocks every time.  Providing the models with opinionated structure [15:17] narrows down the AI's options enabling  it to generate consistent UIs faster. So, [15:24] we've seen how to hook up an agent, handle state,  and mitigate latency. But, here's why I think that [15:29] Flutter is actually the perfect uh built the  perfect place to build genuine experiences. [15:37] The Flutter team's fundamental belief is that  you shouldn't have to build an app three times, [15:41] multiple times, to get the same functionality,  genuine or otherwise. Flutter's creators had [15:47] this motto, build for people, not platforms.  That's why Flutter apps can be deployed across [15:53] every screen that renders pixels, including  Android, iOS, Linux, macOS, and Windows. [15:59] We bypass the native UI components and runtime  bridges that a lot of folks tend to think of when [16:03] they think of cross-platform. That means it comes  with native-like performance since the framework [16:09] draws every single pixel of the UI to the screen  with our graphics engine uh called Impeller. [16:16] Um how many folks here are familiar  with the Notebook LM app? Yeah, okay. [16:21] Well, the Notebook LM app,  now known as Gemini Notebook, [16:24] uh their web app went viral overnight,  and they needed to ship a mobile app ASAP. [16:29] They went with Flutter and built and shipped their  mobile app to both iOS and Android in 7 months. [16:37] And if you have an existing app, right? You  can build a feature with Flutter, for example, [16:42] your genuine experience, and  embed it within your native apps. [16:46] Uh this is a feature that we call add to app. [16:49] So, add to app enables you to build these screens  in Flutter and embed them wherever you want. [16:56] So, the Gemini app, uh have y'all seen the Gemini  app? Use the Gemini app? Cool. So, they had a [17:03] feature called visual layout. The visual layout  team was one of the very first teams to prototype [17:08] what a genuine experience would actually look  like. Then this was like way back in 2023. [17:16] The Gemini app was built natively, but the  visual layout protocol was built with Flutter. [17:20] So, when it came time to ship to users,  they used add-to-app to embed the feature [17:24] directly in all three of their  apps, in iOS, Android, and web. [17:30] So, many of the full-scale Flutter apps that you  have on your phone today started with Flutter [17:34] through add-to-app. We'll often talk to engineers,  and they'll tell us that they used add-to-app as [17:39] an opportunity to evaluate Flutter. And it went  so well that they converted to Flutter full-time. [17:45] For example, Talabat, one of the MENA region's  biggest on-demand delivery platforms, and SoFi, [17:51] a US fintech company that offers a super app for  their over 15 million members. Um, they actually [17:57] also saw a 60% reduction in their codebase.  And so now, to connect everything together, [18:05] So, to connect everything together, ATUI  is a new way to interact with our AI agents [18:11] by translating complicated data into rich,  interactive user interfaces via JSON blueprints. [18:17] It enables more effective communication than  just text by itself. A single JSON response [18:23] can render natively across web, mobile, and  desktop through your app's own design system. [18:32] And we aren't just talking about saving developer  hours, right? We're talking about a paradigm shift [18:36] here. By coupling the standardization of ATUI with  the portability and raw graphics power of Flutter, [18:42] you aren't just building a chatbot, you're  building a dynamic, self-molding user [18:46] experience that runs on phones, desktops, and  web browsers. And you build it once, and your [18:51] agent can live anywhere. So, with that said, let's  get building GenUI together. Thank you. [applause]