Google, Tambo and GenUI: Three Approaches to AI Interfaces Assembled on the Fly

Generative UI goes beyond chatbots: the model doesn't just write an answer, it also decides which interface to show the user at a given moment. A new breakdown explains where this approach is genuinely useful, from analytics to bookings, and why the choice of architecture matters more here than the fashion for agentic systems.

How GenUI differs

In an ordinary AI chat, the user gets text, sometimes with a table or markdown formatting, but the screen logic is still hard-wired into the product in advance. Generative UI goes further: the model can pick the right component itself, build a form, show an insight card, a chart or navigation through results. This is especially useful where the interface depends not on a single scenario but on the context of the request, the type of data and the user's next step.

"The interface is too variable to hardcode every state."

The material identifies four typical cases where GenUI is truly justified: when the generated result must live on as an editable artifact, when an agent needs to collect structured data through a form, when an answer is better shown visually than in paragraphs of text, and when the user needs to move between several options that were found. The point is not to make the interface flashier, but to remove unnecessary cognitive load and speed up work with the answer.

Three assembly models

The author examines three architectural approaches, each with its own balance between model freedom, UX quality and risk to the product. The most obvious path is to let the model generate HTML and render it in the browser right away. That is fast for a prototype, but in production it is fragile: the model easily breaks the design system, invents nonexistent attributes and raises additional security questions.

• HTML generation: maximum freedom for the model, minimum control for the product team.
• Declarative approach: the agent describes the interface through JSON and a component vocabulary, and the client renders it within its own UI kit.
• Choosing a prebuilt component: the agent doesn't lay out the interface, but plugs data into pre-built cards, charts and forms.

The middle path is declarative assembly, where the agent doesn't write code directly but works as a composer of atomic elements. The article notes that this approach is formalized by Google's A2UI protocol, published in December 2025. The most controllable option is a library of prebuilt components: the model has less freedom, but the interface stays predictable. This approach is a poorer fit for an unlimited number of scenarios, but works best where UX matters more than improvisation.

Why Tambo was chosen

The practical case in the article involves an AI assistant for marketing analytics. Such a product has a workspace with tables and slices where the user analyzes data, and a chat with an agent that helps find insights. The problem is that it is useful for the agent to show mini-charts, cards and summaries, but it must not be allowed to freely rearrange the main workspace. For an analytics product this is the key artifact, and any extra dynamism there only gets in the way.

The author ultimately settled on Tambo, an open-source React framework that follows the prebuilt-component model and adds a lifecycle, state and two-way communication between the UI and the agent via AG-UI. Components are registered with descriptions and Zod schemas for props, after which the agent chooses what to show and can stream data into the component in real time. In this setup the workspace stays stable and prebuilt, while all generative elements (charts, cards, quick summaries) live in the chat and don't break the core UX.

What this means

Generative UI is ceasing to be a demo experiment and becoming an applied layer of AI products. The main takeaway is simple: choose not the trendiest framework, but the degree of freedom you are ready to give the model without harming the interface, security and the logic of the user's workflow.