Generative UI
The agent renders or changes interface elements, not just chat text.
Problem
Chat is a poor format for many answers. A comparison belongs in a table, a trend in a chart, a booking in a form, a filter change on the dashboard itself. When the agent can only reply in text, users have to read paragraphs and then go do the work in a different screen.
- Many answers are clearer as tables, charts, forms or changed views.
- Users still want to ask in plain language.
- Free-form generated interface code is risky and inconsistent.
- The interface must stay usable when the agent gets something wrong.
Solution
Let the agent respond by changing the interface instead of only writing text. The application exposes a catalog of components (table, chart, form, card, filter, map) and state actions (apply filter, open record, add row), each with a schema. The agent picks components and fills them with data, or emits state updates, through a structured protocol, and the app renders them with its own design system. The user’s input can be chat while the output is the UI changing. Users can edit what the agent produced, and every change can be undone.
Diagram
The agent chooses and fills components; the app renders them. Users see a consistent, editable interface instead of free-form generated code.
When to use
Use it when
- Answers are naturally tables, charts, forms or filtered views
- Users work in an app and want the app itself to respond
- The app has a component library that can be described with schemas
- Actions should be reviewable in a form before they're submitted
Avoid it when
- Short factual answers where text is clearest
- The app has no stable component catalog to expose
- Every UI change would need its own security review
Trade-offs
Gains
- Answers in the most useful form, not just paragraphs
- Users can act directly on what the agent produced
- Consistent look and accessibility, because the app renders everything
Costs
- A component catalog and protocol to design and maintain
- The agent may pick the wrong component or overfill the screen
- Keeping agent state and UI state in sync is tricky
Worked example
An executive strategy dashboard where leaders ask questions in a chat box next to the main view.
- ExecutiveTypes: “Show me initiatives over budget in EMEA.”
- AgentDoesn’t reply with text. It emits
apply_filter(region="EMEA", status="over_budget"), and the main table updates to 7 rows. - Executive“Compare spend vs. plan for the top 3.”
- AgentEmits a chart component with 3 initiatives, planned vs. actual spend, using the app’s own chart style. It adds one sentence of text: “Data Platform is the largest gap at +$1.2M.”
- ExecutiveClicks into the chart and drags Data Platform onto a watchlist. Clicks undo on an earlier filter. Every agent change is in the undo history.
Failure modes
| Failure | Symptom | Mitigation |
|---|---|---|
| Wrong component | Agent shows a chart where a number would do | Component descriptions say when to use each; evaluate choices |
| Free-form UI code | Inconsistent, inaccessible or unsafe generated markup | Only catalog components with schemas; the app renders them |
| State drift | Agent thinks a filter is applied that the user removed | Send current UI state to the agent with every request |
| Irreversible UI actions | Agent-submitted forms commit changes the user didn't review | Agent fills forms; the user submits, or Human-in-the-Loop gates it |