Generative UI

also known as Agent-Generated Interface, 生成UI, Dynamic Agent UI

Let the agent decide which interface components to render at runtime and stream them to the frontend over a typed protocol, so the surface follows the agent's output instead of being hardcoded.

Context

A team is building a user-facing agent whose output is open-ended: it may answer in prose, show a chart, ask a clarifying question with buttons, render a form, or surface a confirmation step before acting. The frontend is a web or mobile client built ahead of time, with a fixed set of components wired to a fixed response shape. The team has to decide how an interface designed in advance can present whatever the agent decides to produce at runtime.

Problem

A hardcoded interface can only render the response shapes its developers anticipated, so every new agent capability — a new card type, a new interactive step — needs a coordinated frontend release before users can see it. Pushing the raw model output to a generic chat bubble avoids that coupling but throws away structure: the client receives text and cannot tell a chart from a form from a confirmation prompt, and cannot route an interactive step like a button click back into the agent. Embedding model-generated executable code in the page removes the limit but opens an injection surface the team cannot audit.

Forces

An interface built in advance cannot enumerate every output shape an open-ended agent will produce.
Coupling the frontend to a fixed response schema forces a coordinated release for every new agent capability.
Sending declarative interface data is auditable; sending executable code is flexible but an injection risk.
The frontend and the agent backend evolve on different schedules and are often owned by different teams.
Interactive steps (button clicks, form submits) must round-trip back into the agent's loop, not just render once.

Example

A support agent normally answers in text, but for a refund it needs to show the order, a reason dropdown, and a confirm button. The frontend was not built with a refund widget. With Generative UI the agent emits a declarative form-and-confirm component over the event stream; the generic renderer draws it, the user picks a reason and clicks confirm, and the click returns to the agent as an event — all without a frontend release for the new flow.

Diagram

sequenceDiagram participant Agent participant Proto as Agent-to-UI Protocol participant R as Generic Renderer participant User Agent->>Proto: emit text_delta + component(form, props) Proto->>R: typed UI events R->>User: render widget from declaration User->>R: click confirm R->>Proto: interaction event Proto->>Agent: resume loop with user input

Solution

Therefore:

Specify an event vocabulary that carries declarative interface structure (component, props, layout), shared state, and interaction requests rather than raw markup or code. The agent emits these events on the same stream as its text; a generic client renderer maps each declared component to a real widget and routes user interactions (clicks, form submits) back to the agent as new events. Because the contract is the protocol, the same frontend works against any agent backend that speaks it, and the agent can introduce new interface shapes without a frontend release. Declarative payloads (for example JSON Lines describing the component tree) keep the surface auditable; executable payloads are avoided unless sandboxed.

What this pattern forbids. The agent cannot ship raw markup or executable code to the client; it may emit only declarative components drawn from the protocol's typed vocabulary, and the renderer must reject events outside that vocabulary.

And the patterns that stand alongside it, or against it —

complementsStreaming Typed Events★★— Push partial results to the client as typed events as they become available, rather than waiting for the full response.
complementsHuman-in-the-Loop★★— Require explicit human approval at defined points before the agent performs an action.