Conversational Generative UI Surfaces

Definition

Conversational generative UI combines natural-language interaction with rich, interactive web components in one surface. Chat or voice handles discovery and intent, while typed data, visualizations, controls, and deep web views appear in context instead of forcing a user to switch between a chatbot and a separate application.

Guillermo Rauch describes this convergence as “natural language woven into the fabric of the page itself.” The design is not text replacing web pages: the conversation provides the control and discovery layer, and the page provides depth, refinement, navigation, and durable visual structure.

Why it matters

Text-only answers become difficult to scan when a question needs comparisons, timelines, evidence coverage, filters, or interactive exploration. A conversational surface can select the appropriate structured view at the point of need while preserving the ordinary web page as a stable, shareable place for deeper analysis.

This is particularly useful for knowledge systems: the user can ask an open-ended question, receive a bounded evidence-backed view, refine it through visible controls, and open the underlying sources without leaving the research flow.

How it works

The current page contributes explicit, validated context such as the active landscape, snapshot, filters, or selected entries.
An agent maps the user's request to a typed tool rather than generating arbitrary application code.
The tool retrieves and calculates a validated data result.
The result renders through either a fixed component or a JSON layout constrained to an approved component/action catalog.
Factual values bind to validated data paths; the generated layout does not invent data.
The user can refine the result and open a canonical page for more depth.
The same underlying result can degrade to text plus deep links in channels that cannot render the rich interface.

JSON Render is a relevant implementation pattern: it constrains generated JSON to a developer-defined catalog of components, actions, bindings, and validation. For higher-stakes evidence views, fixed typed components remain the safer default; catalog-constrained composition can be added behind evaluation and feature gates.

Key examples

A question about business adoption renders an evidence-maturity matrix rather than a wall of Markdown.
A question about tools renders a capability comparison with direct evidence links and Research Set actions.
A periodic agent brief arrives as concise text in Slack but links to a full, interactive web landscape using the same snapshot and filters.
A user starts with chat, refines the output using visible controls, and opens a canonical page without losing the question's context.

Common misconceptions

Generative UI does not require executing model-generated HTML or JavaScript.
Chat and web pages are complementary surfaces rather than mutually exclusive replacements.
A personalized layout does not justify personalized or invented facts.
A component catalog constrains presentation; server-side evidence contracts must still constrain data and claims.
More dynamic UI is not always better. Simple questions should remain concise.

Current state

AI SDK supports mapping typed tool results to application components. JSON Render demonstrates a more compositional approach in which a model produces a streamed JSON tree constrained to a developer-defined catalog. These approaches can coexist: fixed evidence-critical views first, followed by bounded generated composition for exploratory layouts once security, accessibility, performance, and task-quality evaluations pass.

For AI Wiki, the applicable design is a contextual Landscape copilot, shared typed tool contracts across Ask and Landscape pages, one-click deep links, and an optional catalog-constrained composition layer that cannot change evidence semantics or execute arbitrary code.

Open questions

Which landscape tasks benefit measurably from composition over fixed views?
How should generated layouts be evaluated for accessibility and misleading emphasis?
Which component and action catalog is small enough to remain reliable?
How should rich views degrade across Slack, WhatsApp, email, or MCP clients?
When should an ephemeral generated view become a shareable saved artifact?