# Generative UI

Generative UI means a model composes the interface at run time instead of using fixed screens. Learn the approaches, AG-UI, MCP Apps, A2UI, safety and accessibility.

## Overview

Most software has fixed screens. A designer decides in advance what the flight search page looks like, and every user sees the same layout. Chat assistants went to the other extreme: everything is text. Generative UI sits between the two. The model looks at the request and the data, then decides what interface to show: a comparison table for three laptops, a map with pins for a walking tour, a form to collect missing booking details, a chart for a sales question. The screen is composed for this moment, for this user.

There are different degrees. At the light end, the model chooses which pre-built component to show and fills in its data. In the middle, the model writes a structured description of a layout using components from an approved design system, and the app renders it. At the heavy end, the model writes actual interface code, such as HTML and JavaScript, which runs in a sandbox. Each step adds flexibility and adds risk.

An everyday comparison is the difference between a printed menu and a good waiter. The menu is fixed: everyone gets the same pages. A good waiter listens and shows you the three dishes that suit your diet, sketches the wine pairing on a notepad and brings the dessert card only when you are ready. Generative UI tries to make software behave more like the waiter, while still using the restaurant's real dishes, not invented ones. This page explains the approaches, the protocols that connect agents to user interfaces, and how to keep the result safe, consistent and accessible. It builds on [structured outputs](/tools/structured-outputs), [function calling](/tools/function-calling) and [MCP](/tools/mcp).

## What it is

A generative UI system has a few recurring parts.

| Part | Role |
|---|---|
| Model or agent | Decides what to show based on the request, context and data |
| Component catalogue | The approved building blocks: cards, tables, charts, forms, buttons |
| UI specification | A structured description (often JSON) of which components to show and with what data |
| Renderer | Client code that turns the specification into real, native interface elements |
| Agent-to-UI protocol | The message format that streams text, tool calls, state and UI between agent and front end |
| Sandbox | An isolated frame where generated or third-party interface code runs |
| State and events | Shared data and user actions that flow back to the agent |
| Guard rails | Validation, design rules and policies applied before anything is shown |

The key design choice is how much the model controls. Choosing from a catalogue keeps the brand, behaviour and accessibility under the developer's control. Generating code allows almost anything but makes consistency and safety much harder.

## Where it came from

Ideas about adaptive and personalised interfaces are decades old, but large language models made run-time interface composition practical. Early work used [function calling](/tools/function-calling) to map tool results to components. In March 2024 Vercel's AI SDK 3.0 introduced generative UI for React, linking model tool calls to streaming React Server Components: a weather tool could show a loading state and then a forecast card.

In 2025 the focus shifted to protocols. CopilotKit introduced AG-UI, the Agent-User Interaction Protocol, in May 2025: an open, event-based protocol that streams messages, tool calls, state updates and lifecycle signals between an agent back end and a front end. In October 2025 OpenAI announced the Apps SDK, letting third-party apps show interactive interface inside ChatGPT, sharing context through MCP. A community project, MCP-UI, had already explored adding interface resources to MCP servers. In November 2025 MCP core maintainers at OpenAI and Anthropic, with the MCP-UI creators, proposed the MCP Apps extension, and in January 2026 MCP Apps became the first official MCP extension. Tools reference `ui://` resources that hosts render in sandboxed iframes, and the MCP project listed ChatGPT, Claude, goose and VS Code among supporting hosts.

Also in November 2025 Google Research published "Generative UI: LLMs are Effective UI Generators" and described generative UI experiments in the Gemini app and in AI Mode in Google Search. In its human preference tests, expert-made websites still ranked highest, but generated interfaces came close and were preferred over plain text and standard search results, with the caveats that generation could take a minute or more and outputs were sometimes inaccurate. Separately, Google has released A2UI, an open-source declarative format under the Apache 2.0 licence in which agents send JSON that clients render with their own trusted components; at the time of writing the project describes itself as an early-stage public preview.

## How it works

### Approach 1: choose a component, fill the data

The simplest form uses tools as a switch. Each tool result maps to one component: `get_weather` renders a weather card, `search_flights` renders a flight list. The model decides which tool to call; the developer decides how each result looks. This is reliable, easy to test and fully on-brand, but the model cannot invent new layouts.

### Approach 2: structured UI specifications from a design system

The model outputs a structured description of an interface using only components from a catalogue. The app validates it against a schema and renders it with native components. A minimal, illustrative specification (not tied to any one protocol) might look like this:

```json
{
  "type": "Column",
  "children": [
    { "type": "Heading", "text": "Three laptops under £900" },
    { "type": "ComparisonTable",
      "columns": ["Model", "Weight", "Battery", "Price"],
      "rows": [["A14", "1.2 kg", "14 h", "£849"],
               ["B13", "1.0 kg", "11 h", "£899"],
               ["C15", "1.6 kg", "16 h", "£799"]] },
    { "type": "Button", "label": "Compare screens", "action": "compare_screens" }
  ]
}
```

The renderer knows how to draw `Column`, `Heading`, `ComparisonTable` and `Button` in the house style, with correct accessibility behaviour. Unknown types are rejected. Actions are names the app has registered, not arbitrary code. A2UI follows this philosophy, describing itself as "safe like data, but expressive like code": a flat list of components referring to each other by ID, which a model can produce incrementally. Constrained decoding or [structured outputs](/tools/structured-outputs) help the model produce valid specifications.

### Approach 3: generated code in a sandbox

The model writes HTML, CSS and JavaScript, or a framework component, and the host runs it in an isolated frame. This is the most expressive approach and suits one-off visualisations, simulations and mini-tools. Google's generative UI research used this style, with a strong model, tools such as image generation and web search, detailed system instructions and post-processing to fix common errors. The cost is higher latency, more variable quality and a much larger safety surface.

### Agent-to-UI protocols

An agent and its front end need a shared language. AG-UI defines event types in groups: lifecycle (`RUN_STARTED`, `RUN_FINISHED`, `RUN_ERROR`), text messages (`TEXT_MESSAGE_START`, `TEXT_MESSAGE_CONTENT`, `TEXT_MESSAGE_END`), tool calls (`TOOL_CALL_START`, `TOOL_CALL_ARGS`, `TOOL_CALL_END`) and state (`STATE_SNAPSHOT`, `STATE_DELTA`, `MESSAGES_SNAPSHOT`). State deltas use JSON Patch so only changes travel, and the reference HTTP client supports server-sent events and a binary format. MCP Apps works at a different level: an MCP tool points to a `ui://` resource containing HTML; the host fetches it, renders it in a sandboxed iframe and exchanges JSON-RPC messages with it over `postMessage`, so interface actions travel through the same path as tool calls. A2UI is a payload format that can travel over transports such as [A2A](/tools/a2a) or AG-UI. These pieces are complementary rather than direct competitors: one streams agent events, one packages interactive apps for MCP hosts, one describes native layouts.

### The interaction loop

Generative UI is two-way. The user clicks a button or submits a form, the event goes back to the agent as structured data, the agent updates state or calls tools, and new interface flows back. A good design keeps shared state explicit, so the model, the interface and the back end agree on what the user has chosen, and lets the user correct things directly rather than by typing.

### Safety and consistency

Several controls, in the spirit of [guardrails](/tools/guardrails), apply whichever approach is used. Validate every specification against a schema and a component allow-list. Keep actions to a registered set and require confirmation for anything consequential, such as a purchase, with a [human-in-the-loop](/tools/human-in-the-loop) step. Render generated or third-party code only in sandboxed frames with a strict content security policy, no access to the host page and limited network access. MCP Apps relies on iframe sandboxing, templates that hosts can review in advance, auditable JSON-RPC messages and optional user consent for interface-initiated tool calls. Treat data shown in generated interfaces as untrusted, because content fetched by the agent may contain [prompt injection](/tools/prompt-injection-defense) or misleading text. Use the design system's tokens for colour, spacing and type, so generated screens look like the rest of the product.

### Accessibility

A generated interface must still meet accessibility standards. With a component catalogue, accessibility lives in the components: correct semantics, labels, focus order, keyboard support and contrast are built once and reused. With generated code, these must be checked on every output, for example with automated accessibility checks after generation and by rejecting outputs that fail. Always provide a text equivalent of the key information, so screen-reader users and anyone who prefers text can get the same answer, and keep layout changes predictable so users are not disoriented.

### When to use it

A rough rule helps:

```text
value(GenUI) ≈ variety_of_requests × benefit_of_visual_form − (latency_cost + risk_cost + consistency_cost)
```

`variety_of_requests` is how varied users' needs are; `benefit_of_visual_form` is how much better a chart, table or form is than text for those needs; `latency_cost` is the waiting time added by generating interface; `risk_cost` covers safety and correctness failures; and `consistency_cost` is the price of screens that look or behave differently each time. Generative UI pays off when requests are varied and visual answers help a lot. For a fixed, high-traffic flow such as a checkout page, a hand-designed screen usually wins.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Generative UI | Interface composed by a model at run time |
| Component catalogue | The approved set of interface building blocks a model may use |
| UI specification | A structured, usually JSON, description of an interface |
| Renderer | Client code that turns a specification into native elements |
| AG-UI | An open, event-based protocol between agent back ends and front ends |
| MCP Apps | The MCP extension that lets tools return interactive HTML rendered in sandboxed frames |
| `ui://` resource | An MCP resource containing an interface template |
| A2UI | Google's open declarative format for agent-generated native interfaces |
| State delta | A small update to shared state, sent instead of the whole state |
| Sandboxed iframe | An isolated frame that limits what embedded code can do |
| Allow-list | The explicit list of components or actions that are permitted |
| Text equivalent | A plain-text version of the information shown visually |

## A worked example

This is an illustrative scenario, not a description of any real company.

A travel company's assistant answers questions in a chat panel. Before generative UI, a request such as "compare hotels near the conference centre for 3 nights under 180 pounds a night" produced six paragraphs of text. Users scrolled back and forth and often asked follow-up questions about distances and prices.

The team adds generative UI using a catalogue of eight components: `HotelCard`, `ComparisonTable`, `Map`, `PriceChart`, `DateRangePicker`, `Form`, `Button` and `Notice`.

1. The agent searches inventory and finds four hotels. It returns a specification: a `Map` with four pins and the conference centre, a `ComparisonTable` with price, walking time and rating, and a `Button` labelled "Hold room" for each row.
2. The front end validates the specification. One row's `action` is `book_now_and_pay`, which is not registered; the renderer replaces it with the registered `hold_room` action and logs the mismatch.
3. Events stream over an event protocol: text messages first, then a state snapshot with the four hotels, then the interface. The text summary appears in under a second; the table and map in about two seconds.
4. The user drags the date range picker to two nights. A state delta updates prices; the agent recomputes totals without regenerating the whole layout.
5. Clicking "Hold room" opens a `Form` asking for name and email, pre-filled from the profile. Submitting requires a confirmation step. No payment happens without the separate checkout flow.
6. Every screen also includes a short text summary for screen readers, and all components were tested once for keyboard and contrast compliance.

In the illustrative pilot, follow-up questions per session drop from 3.1 to 1.4, and the team spends its effort improving the eight components rather than reviewing generated code.

## Strengths and limitations

**Strengths:**

- Shows information in the form that fits it: tables for comparisons, maps for places, forms for inputs.
- Lets one assistant serve many tasks without a hand-built screen for each.
- Reduces typing by letting users click, drag and choose.
- Component catalogues keep brand, behaviour and accessibility consistent.
- Open protocols let the same agent drive different front ends.
- Two-way state makes collaboration between user and agent clearer.

**Limitations:**

- Adds latency, especially when the model writes full interface code.
- Generated code can be wrong, inconsistent or unsafe without strong sandboxing.
- Screens that change shape each time can confuse users and complicate testing.
- Accessibility must be guaranteed for every output, not designed once.
- Protocols and formats are young, with versions still changing.
- Analytics, support and documentation are harder when no two screens are the same.

## How it compares with alternatives

| Approach | How the interface is made | Flexibility | Consistency and safety | Best for |
|---|---|---|---|---|
| Fixed screens | Designed and coded in advance | Low | High | Core, high-traffic flows |
| Text-only chat | Model writes prose or Markdown | Medium for content, none for layout | High, but weak for data | Simple answers and explanations |
| Component selection (tool to component) | Model picks a component; developer designs it | Low to medium | High | Common, well-known result types |
| Specification from design system (e.g. A2UI-style) | Model composes approved components | Medium to high | High if validated | Assistants with varied tasks |
| Generated code in sandbox (e.g. MCP Apps, research systems) | Model or third party writes HTML and JavaScript | Very high | Lower; depends on sandbox and checks | Visualisations, one-off tools, third-party apps |

## Practical guidance and best practices

1. Start with a small component catalogue that covers the most common answers, and grow it from real usage.
2. Have the model emit structured specifications validated against a schema; reject or repair anything invalid.
3. Keep actions to a registered allow-list and require confirmation for anything that spends money or changes data.
4. Run generated or third-party code only in sandboxed frames with a strict content security policy.
5. Stream text first and interface second so users are never staring at a blank panel.
6. Build accessibility into components, and always include a text equivalent of the key information.
7. Use design tokens so generated screens match the product's look.
8. Keep shared state explicit and send small updates instead of regenerating whole screens.
9. Log specifications and user events so you can test, debug and evaluate; see [evals](/tools/evals).
10. Use fixed screens for critical, high-volume flows and reserve generative UI for varied needs.

## Common mistakes

- Letting the model generate arbitrary code in the main page instead of a sandbox.
- Trusting model-generated action names or links without checking them against an allow-list.
- Forgetting accessibility because "the model will handle it".
- Regenerating the entire interface for every small change, which feels slow and jumpy.
- Using generative UI for a stable flow where a designed screen is faster and clearer.
- Displaying fetched content in rich components without treating it as untrusted.

## Frequently asked questions

### Is generative UI the same as AI tools that generate app code for developers?

No. Code-generation tools help developers build fixed screens before release. Generative UI composes or generates the interface at run time, for each user and request, inside the running product.

### Which approach should I start with?

Usually component selection or structured specifications from a design system. They give most of the benefit with strong control over brand, safety and accessibility. Move to generated code only for cases that truly need it.

### How do AG-UI, MCP Apps and A2UI relate?

AG-UI is an event protocol between an agent back end and a front end. MCP Apps lets MCP tools return interactive HTML interfaces that hosts render in sandboxed frames. A2UI is a declarative format for describing native interfaces. They work at different levels and can be combined.

### Is generated interface code safe to run?

Only with strong isolation. Run it in a sandboxed frame with a strict content security policy, no access to the host page or its cookies, limited network access and user confirmation for consequential actions.

### Does generative UI hurt accessibility?

It can if each output is new code. With accessible components and a text equivalent for every answer, it can meet the same standards as fixed screens.

### How do I test something that changes every time?

Test the components and the validator thoroughly, then test the model's specifications with evaluation sets: check validity, correct data, correct actions and accessibility on many sample requests.

## Glossary

- Generative UI: interface composed by a model at run time.
- Component catalogue: approved building blocks a model may use.
- UI specification: structured description of what to render.
- Renderer: client code that draws the specification.
- AG-UI: event protocol between agents and front ends.
- MCP Apps: MCP extension for interactive interface resources.
- A2UI: declarative format for agent-generated native interfaces.
- Sandboxed iframe: isolated frame for untrusted code.
- Design tokens: shared values for colour, spacing and type.
- State delta: a small change to shared state.
- Text equivalent: plain-text version of visual information.

## Summary

Generative UI lets a model decide what interface to show at run time: choosing a component, composing a layout from an approved catalogue, or writing interface code that runs in a sandbox. Protocols such as AG-UI, MCP Apps and A2UI connect agents to front ends at different levels, and at the time of writing they are young and still changing. The more the model controls, the more flexibility you gain and the more you must invest in validation, sandboxing, design consistency and accessibility. Start with a small, accessible component catalogue, validate every specification, restrict actions, stream text first, and keep fixed screens for the flows where predictability matters most.