Generative UI: when AI decides the interface

What is it in practice?

The screen stops being a fixed list of views and becomes a response to what the person is doing. A travel assistant can show a date picker when the conversation reaches dates, and a map when someone asks about nearby hotels. None of those pieces was on a predefined screen: the model chose them.

It helps to separate it from other forms of AI inside an interface. A chat generates text. A generative UI generates structure: which blocks appear, in what order and with which controls. Chat is a container; generative UI is a way of composing what goes inside it.

What patterns exist?

MetaCTO’s production guide separates three patterns according to how much freedom the model has:

The closer the system gets to generating code at runtime, the harder it is to test and to recover from failures. The guide itself recommends constraining the model to select and configure a fixed inventory of components. That is why most teams start with selection.

Which protocols and SDKs exist today?

Status checked against official sources on November 1, 2026. All of this moves fast: check the date on your sources.

The design differences matter. In A2UI the client defines a catalog of trusted components, such as Card, Button or TextField, and the agent can only request pieces from that catalog: the interface uses your own components and styles. In MCP Apps the server brings its own HTML, isolated in an iframe: it is more flexible, but it looks less like your product. AG-UI is not a screen format but the channel the messages travel through. To understand the tools side, see MCP explained for designers.

Why does it matter to a designer?

Because generative UI moves decisions that used to belong to the designer to a model that decides in real time. That has three consequences.

The first is predictability. Someone who uses software every day learns its screens; if the layout changes on every visit, that learning is lost. It matters most in products used repeatedly, where efficiency comes from familiarity. The Lazarev Agency article suggests wrapping generative regions in a fixed navigation and layout, so nobody loses their bearings when the content changes.

The second is the component vocabulary. The same article says to design that vocabulary first, because a model composes well only from parts built to recombine, and inconsistent components produce inconsistent generated screens. A well-documented design system helps here. Accessibility depends on it too: if the model chooses reading order and headings, nothing guarantees a stable structure for a screen reader, unless the catalog components already solve it.

The third is designing the exception states. A generated interface will sometimes fail. The same article treats empty, error and low-confidence states as core deliverables, because there is no fixed screen to fall back on.

How do you apply it in a product?

Four steps to start:

1. Define the catalog. List the allowed components (card, list, short form, chart, action button), each with its properties.
2. Fix the structure. Keep navigation and layout stable around the generative area.
3. Design the low-confidence states. When the model is unsure, show something different: a clarifying question or a simpler view.
4. Keep a human checkpoint. For actions with real effects, the interface must show what will happen and ask for confirmation. What is generated can be proposed; it should not execute on its own. See action approval.

It suits products where broad personalization is part of the value. In a simple, mostly static product, a fixed interface is usually better.

When should you NOT use generative UI?

• When the task structure is finite and known. A form gives a clear state and testable validation.
• When there are real effects. Moving money, sending messages or writing to a system of record needs a designed interface with explicit confirmation.
• When there are audits. A screen that changes is hard to use as evidence of what the person saw, unless you store what was shown.
• When latency matters. Generating the interface adds waiting time compared with a screen that is already built.

Example

Illustrative example: a personal finance dashboard. Someone asks “How much did I spend on food this quarter?”. The model picks among three components from the catalog (a bar chart, a table and a summary card) and fills in their data. All three were already designed, with their loading, error and empty states. The only thing the AI decided was which one to use. If the person wants to move money from that dashboard, a fixed form with confirmation appears, not a generated component.

Common mistakes

• Letting the model generate code in production without tests that cover those cases.
• Changing the layout on every visit and disorienting people who work in the same screen every day.
• Generating components without a design system behind them: the result looks coherent only in the demo.
• Not designing the error state or the low-confidence state.
• Using generative UI for actions that should have a form and a confirmation.
• Basing a decision on an old protocol version: A2UI and MCP Apps were announced less than a year ago and are still changing.

Sources

• Google Developers Blog: Introducing A2UI
• A2UI: project site
• MCP blog: MCP Apps (January 26, 2026)
• AI SDK: generative user interfaces
• AI SDK: introduction
• AI SDK RSC: overview
• AG-UI: documentation
• MetaCTO: Generative UI, When AI Should Build the Interface
• Lazarev Agency: Generative UI design