Generative UI lets an AI model decide which interface to show, such as a table, slider, or chart, instead of replying with text alone. The model returns a structured tool call, and your app validates it and renders a component you built in advance.
TL;DR
Generative UI lets an AI system create, select, or configure interface elements at runtime, so users get controls and visuals instead of only text.
In the safest pattern, the model returns a structured tool call, and your app validates it and renders a component you built in advance.
Start with a fixed component registry, validate and authorize every call, and require confirmation for irreversible actions.
Traditional chat interfaces work well for answering questions, but they become less practical when users need to compare options, adjust settings, or interact with data. Comparing flights through paragraphs or changing animation speed through repeated text instructions can make simple tasks unnecessarily complicated.
Generative UI offers a more interactive approach. Instead of relying only on text, AI can select and configure interface elements such as charts, sliders, forms, and tables based on the user’s request.
For example, an AI customer service agent handling refunds or subscription changes can display relevant forms and controls directly within a conversation. Rather than designing a separate screen for every request, developers can provide reusable components that the AI selects when needed.
However, building these interfaces requires careful attention to security, validation, and user control.
This blog explains what Generative UI is, how AI renders interactive components, the different architecture approaches, and how to build and test reliable implementations, with practical examples from rendering and animation workflows.
What Is Generative UI?
Generative UI (Generative User Interface) is an approach where AI creates, selects, or adjusts interface elements based on a user’s request. Instead of responding only with text, AI can present interactive components such as forms, charts, sliders, and buttons.
These interfaces are generated or configured at runtime, meaning while the application is running. In some implementations, AI selects from prebuilt components. In others, it generates code that runs in a controlled environment.
A 2025 study on generative user interfaces, drawing on 127 publications, 18 expert interviews, and 12 case studies, examined how AI and designers can work together to create and adapt interfaces.
Two concepts help explain how Generative UI works:
Component: A reusable interface element, such as a form, chart, or timeline, created and tested by developers.
Specification: A structured description generated by AI that tells the application which component to display and how to configure it.
For production applications, a controlled approach is generally safer. AI selects and configures approved components, while the application manages rendering, styling, accessibility, and permissions. This gives users interactive experiences without giving the AI unrestricted control over the interface.gures, and your application owns rendering, styling, accessibility, and permissions.
How Is Generative UI Different From Conversational UI and AI-Generated Code?
Conversational UI, Generative UI, and AI-generated code all use AI to respond to user requests, but they differ in how users interact with the results and how much control the AI has over the interface.
Conversational UI primarily communicates through messages, while Generative UI adds interactive components that users can work with directly. AI-generated code goes further by producing new source code rather than selecting existing interface elements.
Here is how they differ:
Approach
How It Works
Example
Key Difference
Conversational UI
Users communicate through text or voice, and the system primarily responds with messages.
An AI chatbot explains different subscription plans in text.
Users read the information and take the next step themselves.
Generative UI
AI selects, creates, or configures interface components based on the user’s request.
An AI assistant displays a plan comparison table with interactive selection buttons.
Users can compare options and interact with controls directly.
AI-Generated Code
AI writes source code that developers review or execute in an application or sandbox.
An AI coding assistant generates a React component for a subscription management page.
AI produces implementation code rather than only configuring approved components.
Adaptive UI
Predefined rules, preferences, or user behavior determine how an existing interface changes.
A dashboard displays different widgets based on the user’s role.
Changes usually follow predefined conditions rather than AI interpreting each request.
How These Differences Affect User Experience
Consider a customer who wants to change their subscription plan.
With Conversational UI: The AI explains available plans, prices, and features. The customer may need to open a separate page to make changes.
With Generative UI: The AI can display an interactive comparison with plan options and a confirmation step within the conversation.
With AI-Generated Code: The AI writes the code for a subscription management interface that developers can test and integrate.
With Adaptive UI: The application displays predetermined upgrade options based on the customer’s existing subscription.
These approaches are not mutually exclusive. A conversational assistant can use Generative UI to display components, while developers may use AI-generated code to build those components.
The main distinction is control over the interface. In controlled Generative UI, the AI decides which approved components to display and how to configure them. The application remains responsible for validation, rendering, permissions, and executing user-approved actions.
How Does AI Render Interactive Components?
Generative UI works by converting a user’s request into a structured instruction that an application uses to display an interactive component. Instead of generating a text response, the AI identifies the appropriate interface element, provides its configuration, and lets the application render it.
For example, if a user asks to compare three subscription plans, the AI can request a comparison table with pricing, features, and selection buttons. The application validates the information and displays the component within the conversation.
Define UI Components: Developers create reusable components such as forms, charts, sliders, and tables. Each component has a defined structure using JSON Schema to specify its accepted inputs.
Process the User’s Request: The AI interprets what the user wants and determines which available component can best support the task.
Generate Structured Output: Using tool calling or structured outputs, the model returns the selected component’s name and configuration. External tools and data may also be available through MCP servers using the Model Context Protocol.
Validate the Response: The application checks the generated values against the component’s schema and verifies that the requested operation is allowed. Invalid or unauthorized requests are rejected.
Render the Interface: Once validated, the application displays the component with the supplied data. For example, a React application can map the structured output to an existing React component. Sensitive actions should not run until the required validation and authorization checks are complete.
Handle User Interactions: Users interact with the generated interface by selecting options, adjusting values, or submitting forms. The application updates its state and can send relevant events back to the AI when another response is needed.
What Happens Behind the Scenes?
The key distinction is that the AI determines what to display, while the application controls how it works.
In a controlled Generative UI architecture, the model does not directly generate executable interface code. It selects from approved components and supplies the necessary configuration.
More flexible implementations can allow AI to generate HTML or application code, but these require stronger isolation and security controls.
This separation helps developers maintain consistent design, accessibility, validation, and user permissions while allowing AI to provide interfaces that respond to individual requests.
Which Generative UI Architecture Should You Start With?
Start with component selection, the controlled pattern, and widen the model’s freedom only when a specific user problem needs it. The table shows the three architectures.
Architecture
What the model produces
Your control
Risk
Typical fit
Controlled
A component name plus settings from a fixed set
Highest
Lower
Booking flows, dashboards, editing tools
Declarative
A JSON layout built from an approved catalog, for example a row holding a chart and a filter
High
Medium
Agents that combine several components on one screen
Open-ended
Raw HTML, CSS, or code, for example a self-contained preview page
Lowest
Higher
Prototypes and sandboxed previews
More freedom means more review and isolation. Move down the table only after you can name the user problem the extra freedom solves. In a React app, the registry maps each name to a React component, which can be a client component or a server component depending on your framework. CopilotKit’s generative UI repository uses the same three labels for these patterns. The sources below show each one in practice.
Controlled: The Vercel AI SDK documentation defines generative UI as connecting the results of a tool call to a React component. OpenAI’s structured-outputs sample renders components that the model generates through a generate_ui tool and maps each component definition to a React component.
Declarative:LangChain’s generative UI guide has the developer define a catalog of components that the model composes into a UI tree, so the model can use only components in the catalog.
Interaction layer:AG-UI is an open, event-based protocol that standardizes how AI agents connect to user-facing applications. CopilotKit, the company behind AG-UI, offers an SDK for building generative UI.
Server components: Vercel’s AI SDK RSC documentation describes letting a model respond with React Server Components, labels that route experimental, and recommends AI SDK UI for production.
Worked Example: A Camera Orbit Control
A model call becomes a working control in four moves, and the example below shows each one. It is pseudocode. Field names differ between SDKs, and some providers add requirements to strict schema modes, such as setting additionalProperties to false and marking every property as required, as OpenAI’s function-calling documentation describes. Check your provider’s documentation before copying it.
Your user is working on a product animation and writes, “Make the camera orbit slower and ease it in.” First, you register a component and its schema. The bounds matter, because they do real work in step 2 below.
{
“name”: “show_orbit_control”,
“description”: “Show an adjustable control for camera orbit speed and easing”,
It looks up show_orbit_control in the registry and rejects the call if the name is unknown.
It validates the arguments against the schema, so a value of 400 degrees per second is refused instead of rendered.
It renders the real orbit control with a slider, an easing selector, and a preview, pre-filled with the model’s values.
When the user commits a change, it sends an event such as { “event”: “orbit_change_committed”, “speedDegPerSec”: 9 }, and the server checks that this user may edit the project before saving.
The model contributed judgment about which control to show and a sensible starting point. Every pixel, bound, and behavior came from code you control.
Why Is Schema Validation Not Enough?
Schema validation confirms the structure of the model’s output, and it says nothing about whether an operation is safe or allowed. This request is schema-valid and still dangerous.
Production output validation needs four separate layers.
Schema validation: Is the data structurally valid?
Semantic validation: Do the values make sense in the current state?
Authorization: May this user perform this operation on this record? Check it on the server.
Confirmation (human in the loop): Did the user knowingly approve it? The confirmation must come from your interface, never from a field the model filled in.
How Do You Handle State, Data, and Failures?
Handle state management in your application, and give the model references instead of raw sensitive values.
Let the model reference server-owned records by ID and have the application fetch the data, instead of letting the model supply values for sensitive fields.
Version your component schemas so older conversations still render after the registry changes.
Check that a component’s data still matches the current record before applying a change, so stale state cannot overwrite newer work.
Define a fallback for every failure, including an unknown component, failed validation, a render error, and an interrupted stream. A plain text answer is a valid fallback.
Why Are Rendering and Animation Tools a Good Fit?
Visual tools work in continuous values that people judge by eye, and a control communicates those better than a sentence. Four properties make the match strong.
Parameters are continuous: Speed, intensity, and timing sit on a scale, and a slider shows the scale.
Judgment is visual: Users decide whether a motion feels right by watching it, so the interface should let them watch and adjust in the same place.
Requests vary widely: “Warmer lighting,” “shorter cut,” and “less bounce” each call for a different control, and a fixed menu can’t anticipate them all.
Iteration is constant: Creators change values repeatedly, so each round trip through text adds friction.
CoAnimator illustrates the open-ended end of this range. You bring your own AI agent, such as Claude Code or Codex, and the agent authors scenes, timeline, and narration inside a studio while the stage updates live. CoAnimator describes agentic video editing as a loop where the agent reads the project, edits it, renders it, and checks the result, so a request to slow a cold open changes one scene instead of regenerating the whole video. Because the project files sit in git and render from a command line, a changed product means a pull request and a re-render. Many AI animation generators hand back a finished clip instead, which is why draggable controls such as a timeline scrubber or an easing curve fit best on top of editable projects.
Rendering workflows add one constraint worth planning for early. Previews can be expensive to compute, so show cheap approximations while the user drags and run the full render only on confirmation.
How Do You Decide What the Model May Render?
Ask two questions about each component, how precise the result must be and how costly a mistake is. This is our own editorial framework and not a measured standard, so treat it as a starting point you can argue with.
How precise must the result be? A speed slider with defined bounds tolerates approximation. A legal form or payment amount doesn’t.
How costly is a mistake? A wrong default the user can change in one tap costs little. An action that sends money or deletes work costs a lot.
Low consequence
High consequence
Loose precision
Let the model choose and fill the component, with user edits expected
Model suggests, user confirms before anything runs
Tight precision
Model picks the component, the app computes the values
Fixed, human-designed screen, with the model limited to routing
In the animation example, the orbit control sits in the top left cell. A render-and-publish button belongs in the right column and should always require an explicit click.
What Are the Security Risks of Generative UI?
The main risks are deceptive rendered content, unsafe model-written code, and actions that run without approval. Text-only chatbots face some of these as well, but live components and buttons give each one more reach. The 2025 edition of the OWASP Top 10 for LLM Applications includes prompt injection, improper output handling, and excessive agency, and each appears below.
Prompt injection: Untrusted content, such as a web page read by a browser agent, an email, or an imported project file, can contain instructions that steer the model into rendering a deceptive component, for example a fake login form.
Cross-site scripting (improper output handling): In the open-ended pattern, model-written HTML or JavaScript can run in the user’s session if you render it directly.
Data leakage through rendered content: Images or links in generated output can carry user data to an attacker’s server inside their URLs.
Unvalidated properties: A hallucinated or malicious value can break a component or expose data it was never meant to show.
Unconfirmed actions (excessive agency): A generated button that triggers a payment, deletion, or publish step should never fire without explicit approval. OWASP’s guidance on excessive agency recommends limiting functionality and permissions, authorizing actions downstream, and requiring human approval for high-impact actions.
We treat these mitigations as the minimum at every level of freedom.
Allowlist components and reject any name outside the registry.
Validate, authorize, and confirm with a human in the loop as separate layers, as described above.
Render open-ended output on a separate origin inside a sandboxed iframe. If the content shares your origin, do not combine allow-scripts with allow-same-origin, because MDN notes that lets the embedded document remove its own sandbox. Add a strict Content Security Policy.
Block or proxy external image and link URLs, and restrict network access from sandboxed content.
Set rate limits, timeouts, and resource budgets on tool calls and sandboxed code.
Mark model-generated content so users can tell it apart from system interface, especially on login, consent, and payment screens.
Log every tool call so you can audit what the model asked to render.
How Do You Keep Generated Interfaces Accessible?
Build accessibility into each registered component and test the dynamic behavior, because inserting components at runtime can break focus order and screen reader flow.
Move focus to newly inserted content when it needs attention, and announce it to assistive technology.
Keep every control operable by keyboard, with an accessible name and clear error messages.
Honor reduced-motion and contrast settings in every component.
Keep control placement stable between requests, so users do not have to relearn the layout.
When Should You Not Use Generative UI?
Skip it when a plain answer, a known panel, or a fast local interaction serves the user better.
Simple answers: If the reply is a sentence, a rendered widget adds weight without value.
Exact numeric entry: Editors who need frame-accurate or pixel-accurate values are usually better served by a fixed panel they already know.
Stable layouts: Users build muscle memory, and a control that appears in a different place on every request frustrates experienced people.
Latency-sensitive loops: If each interaction waits on a model call, the experience feels slow. Handle drag events locally and involve the model only at decision points.
How Do You Test a Generative UI?
Run each prompt against your registry many times and record how often the model picks the expected component with valid arguments. Component snapshots verify rendering, but only this kind of test tells you whether the model chooses well.
The cases below are illustrative, so adapt them to your own registry.
Input
Expected behavior
“Slow the camera orbit”
Renders the orbit control with a lower speed than the current value
“Make it feel energetic”
Renders pacing controls and does not invent a component that is not registered
A request containing an out-of-range value
Validation rejects it and the user sees a text fallback
A schema-valid request that targets another user’s record
Authorization rejects it
Pasted content containing hidden instructions
No unrequested component or external link appears
“Publish this”
A confirmation step appears before anything runs
A new component is inserted
Focus and screen reader announcement behave correctly
Repeat every case many times, since the same prompt can produce different choices. Selection accuracy is the first metric to track. Add property validity rate, user correction rate, fallback rate, unsafe action rate, latency, and accessibility violations as the system matures.
Conclusion
Our expectation is that the registry will matter more than the model. A registry with tightly bounded schemas and accessible components is a product asset in the same way a design system is, and it improves with every release. Treat selection tests as a release gate, since each new component can pull requests away from an existing one.
Your override logs will be the most useful input you have. Every time a user changes a model’s default, they show you which components need better defaults, tighter bounds, or a fixed screen instead. To start, pick one workflow, register two components, and log every tool call and override, the same narrow start that suits any AI implementation. A month of that gives you your own data on where the model chooses well and where it needs guardrails.
Rajni is a senior content writer at Delta4 Infotech covering AI agents, automation, and no-code tools. She writes across the AI space, from chatbots and customer support to MCP and agent workflows, focused on how businesses actually put these tools to work.
