Developer's guide to Gemini Enterprise and A2UI integration

If you've built a chatbot, you know this conversation: User: "Book a table for two tomorrow at 7pm." A date picker would have ended this in one tap. But until recently, agents had no standard way to render a date picker - or a map, or a multi-select list - inside the chat surface they live in.

They could only return text or markdown for generic usage. Today, we're walking through how to fix that with A2UI , an open protocol for agent-driven user interfaces, and how to integrate an A2UI-enabled agent with Gemini Enterprise (GE) so your agent renders rich and interactive UI natively in the GE chat surface - and in your own custom frontend if you want one. We'll use a working restaurant-finder agent - built with the Google Agent Development Kit (ADK), the A2A protocol, and Gemini - as the reference.

The full source is on GitHub and there's a 2-minute demo video. Gemini Enterprise and A2UI integration demo The problem: agents speak text, but users want UI Most agent frameworks today return strings. That's fine for short answers, but it breaks down quickly: Multi-turn slot filling (date, time, party size) burns turns and patience.

Choices among options (which restaurant? become long bulleted lists the user has to copy-paste back. Spatial information (locations, routes, floor plans) is reduced to addresses.

Developers have tried to patch this by sending HTML or JavaScript fragments, but that introduces real risks: cross-site scripting, UI injection from a remote agent you don't fully control, and visual drift from the host app's design system. What's needed is a way to transmit UI that's safe like data and expressive like code . What A2UI is A2UI is an open protocol, introduced by Google and co-developed with the Flutter team and product teams behind Gemini Enterprise.

Instead of returning text or HTML, an agent returns a JSON payload that describes a UI: a tree of components (Card, Text, Button, ChoicePicker, Image, ...) and a separate data model holding the values those components display. Three properties make this useful in practice: Declarative, not executable.

The client only renders components from a pre-approved catalog , so a remote agent can't inject arbitrary code or steal credentials through a UI widget. The format is a flat list of small JSON messages, so the LLM can emit them incrementally and the client can paint as they arrive. The same agent response renders through Lit, Angular, Flutter, or native mobile.

The agent doesn't know - or care - what's on the other end. A2UI is also transport-agnostic . The messages ride inside whatever pipe you already use: A2A JSON-RPC, AG-UI, WebSockets, SSE.

In our reference implementation, A2UI rides inside the A2A protocol as DataPart objects with the MIME type application/json+a2ui . Where A2UI sits in the stack A2UI is one piece of a four-layer stack. Lit/Flutter/Angular own the rendering.