Google, Tambo, and GenUI: three approaches to AI interfaces built on the fly

Generative UI goes beyond chatbots: the model not only writes a response, but also decides which interface to show the user at a specific moment. A new breakdown explains where this approach is genuinely useful — from analytics to bookings — and why architectural choice matters more than the trend toward agentic systems.

How GenUI Is Different

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

"The interface is too variable to hardcode all states."

The material highlights four typical cases where GenUI is truly justified: if the generated result should live as an editable artifact, if an agent needs to collect structured data through a form, if the answer is better shown visually rather than in paragraph text, and if the user needs to move between multiple found options. The idea here is not to make the interface more impressive, but to reduce unnecessary cognitive load and speed up work with the response.

Three Assembly Models

The author examines three architectural approaches, each with its own balance between model freedom, UX quality, and product risks.

The most obvious path is to let the model generate HTML and render it directly in the browser. This is fast for a prototype, but in production such an option is fragile: the model easily breaks the design system, invents non-existent attributes, and raises additional security concerns.

• 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 dictionary, and the client renders it within its own UI kit.
• Ready component selection — the agent doesn't code the interface but substitutes data into pre-assembled cards, charts, and forms.

The middle path here is declarative assembly, where the agent doesn't write code directly but works as a composer from atomic elements. The article notes that this approach formalizes Google's A2UI protocol, published in December 2025.

The most controllable option is a library of ready components: the model has less freedom, but the interface remains predictable. This approach is worse suited for an infinite 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. In such a product there is a work area with tables and slices where the user analyzes data, and there is a chat with an agent that helps find insights. The problem is that it's useful for the agent to show mini-charts, cards and summaries, but you can't let it freely rebuild the main work area.

For an analytics product this is the main artifact, and any extra dynamism there only gets in the way.

As a result, the author settled on Tambo — an open source framework for React that works on the ready component model and adds lifecycle, states, and bidirectional communication between UI and agent through AG-UI. Components are registered with descriptions and Zod schemas for props, after which the agent chooses what to show and can stream data to the component in real time.

The work area in this scheme remains stable and pre-assembled, while all generative elements — charts, cards, quick summaries — live in the chat and don't break the main UX.

What This Means

Generative UI stops being an experiment for demos and becomes an applied layer of AI products. The main conclusion is simple: choose not the trendiest framework, but the degree of freedom you are willing to give the model without compromising the interface, security, and user workflow logic.