You might have heard the term “Generative UI” on socials.
Every post means something different and most don’t explain what it actually is. Feels mostly like hype. So I spent some time learning about it (and shipped two projects too).
Here’s what I learned.
Generative UI just means the agent can control parts of the interface. Sometimes it picks from components you wrote. Sometimes it picks layouts from a schema. Sometimes it generates raw HTML. That’s it.
The reason posts feel vague is because “Generative UI” covers all three, and people use the term without saying which one they mean.
Here is the diagram of the Spectrum. It runs from more control to more flexibility.
<img src="https://media.daily.dev/image/fetch/s--qbxvIbwi--/f_auto,q_auto/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gyfwn060jcbeaufvmms8.png?_a=BAMAMiWQ0" alt="">
CopilotKit ships support for all three out of the box so I will be using examples from that.
You can try all three patterns live here: <a href="https://langgraph-py.examples.copilotkit.ai" target="_blank" rel="noopener nofollow">https://langgraph-py.examples.copilotkit.ai</a>.
<hr>
1. Controlled
This is the left side of the spectrum. The frontend owns the UI. The agent only decides which predefined component to show and fills it with data.
You pre-build your components, register them as tools using the useComponent hook and the agent picks one when it needs to show something. The layout, styling and interactions never leave your hands.
<pre><code>useComponent({
 name: &quot;pieChart&quot;,
 description: &quot;Displays a pie chart.&quot;,
 parameters: z.object({
 title: z.string(),
 description: z.string(),
 data: z.array(z.object({
 label: z.string(),
 value: z.number(),
 })),
 }),
 render: PieChart,
})
</code></pre>
<img src="https://media.daily.dev/image/fetch/s--28PFIhlt--/f_auto,q_auto/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h88sli08mwr233cnhph6.png?_a=BAMAMiWQ0" alt="">
Pros: Nothing unexpected ever shows up. Design system stays intact.
Cons: Codebase grows linearly. Every new use case is a new component and a new tool in the agent’s context window.
Most SaaS copilots live here. Linear creating a ticket, Notion AI inserting a table block, any “agent triggers a pre-built card” flow.
docs: <a href="https://docs.copilotkit.ai/reference/v2/hooks/useComponent" target="_blank" rel="noopener nofollow">https://docs.copilotkit.ai/reference/v2/hooks/useComponent</a>
<hr>
2. Declarative (A2UI)
This is the middle of the spectrum. Semi-open, constrained UIs driven by a declarative spec.
You still define a set of components, but you don’t tell the agent which one to use. You give it a schema and it picks the layout, populates the data, and the frontend renders it.
Google shipped a spec called <a href="https://a2ui.org/" target="_blank" rel="noopener nofollow">A2UI (Agent to UI)</a> for this pattern. Other approaches in this bucket: json-render and Hashbrown (you can search if you are curious).
All three work the same way: the agent emits a structured spec, the frontend renders it from a catalog.
On the agent side, you load a schema and expose one tool. On call, push the schema and data through:
<pre><code>const searchFlights = createTool({
 id: &quot;search-flights&quot;,
 execute: async ({ flights }) =&gt; {
 return a2ui.render([
 a2ui.createSurface(&quot;flights&quot;),
 a2ui.updateComponents(&quot;flights&quot;, schema),
 a2ui.updateDataModel(&quot;flights&quot;, { flights }),
 ])
 },
})
</code></pre>
On the frontend, build a catalog from your existing components and pass it to the provider. That’s the whole wiring:
<pre><code>const catalog = createCatalog(definitions, renderers)

&lt;CopilotKit runtimeUrl=&quot;/api/copilotkit&quot; a2ui={{ catalog }}&gt;
 &lt;CopilotChat /&gt;
&lt;/CopilotKit&gt;
</code></pre>
<img src="https://media.daily.dev/image/fetch/s--vD-kZoy8--/f_auto,q_auto/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0c8w1uksk443hknbbtvf.png?_a=BAMAMiWQ0" alt="">
The agent picks components from the catalog, emits the spec and the frontend renders it.
Pros: One tool produces dozens of different interfaces. Backend doesn’t need a new component every time the use case shifts.
Cons: The LLM controls layout. Output varies between runs, sometimes more than you’d like.
I believe most production apps will live here in a year. Controlled is too rigid. The next one is too wild.
docs: <a href="https://docs.copilotkit.ai/generative-ui/a2ui" target="_blank" rel="noopener nofollow">https://docs.copilotkit.ai/generative-ui/a2ui</a>
<hr>
3. Open-ended (MCP Apps, raw HTML)
This is the right end. No catalog, no component map, just a blank canvas. The agent generates UI from scratch.
Two patterns here are worth naming:
<ol>
<li>MCP Apps. The agent controls an external app through MCP. Excalidraw is the usual example: ask for a diagram and the agent draws every pixel on the board from your context.</li>
</ol>
MCP servers can now ship interactive UIs alongside their tool outputs. The host just renders them. It’s already live in Claude and a few other assistants.
<img src="https://media.daily.dev/image/fetch/s--MyE_YNeY--/f_auto,q_auto/https://github.com/modelcontextprotocol/ext-apps/raw/main/media/excalidraw.gif?_a=BAMAMiWQ0" alt="MCP Apps demo">
Implementing the client protocol for your own app from scratch is painful, so CopilotKit ships an <code>MCPAppsMiddleware</code>. Just attach it to your agent and point it at any MCP Apps server.
<pre><code>import { BuiltInAgent } from &quot;@copilotkit/runtime/v2&quot;
import { MCPAppsMiddleware } from &quot;@ag-ui/mcp-apps-middleware&quot;

const agent = new BuiltInAgent({
 model: &quot;openai/gpt-5.2&quot;,
 prompt: &quot;You are a helpful assistant.&quot;,
}).use(
 new MCPAppsMiddleware({
 mcpServers: [
 {
 type: &quot;http&quot;,
 url: &quot;https://mcp.excalidraw.com/mcp&quot;,
 serverId: &quot;my-server&quot;,
 },
 ],
 }),
)
</code></pre>
docs: <a href="https://docs.copilotkit.ai/learn/generative-ui/specs/mcp-apps" target="_blank" rel="noopener nofollow">https://docs.copilotkit.ai/learn/generative-ui/specs/mcp-apps</a>
<ol start="2">
<li>Open Generative UI. The agent generates raw HTML. It renders inside a sandboxed double iframe so it can’t hijack the session.</li>
</ol>
How it works under the hood: it sends a client tool through AG-UI protocol (which transports tools from the front end to the agent) and the agent executes that tool by writing HTML.
On the agent side, there’s almost nothing. One agent, one instruction. The HTML-rendering tool comes from the frontend:
<pre><code>export const agent = new Agent({
 name: &quot;Open GenUI Agent&quot;,
 model: &quot;openai:gpt-5.5&quot;,
 instructions: &quot;You can generate interactive HTML content for the user.&quot;,
})
</code></pre>
On the frontend, it’s one flag:
<pre><code>&lt;CopilotKit runtimeUrl=&quot;/api/copilotkit&quot; openGenerativeUI={true}&gt;
 &lt;CopilotChat /&gt;
&lt;/CopilotKit&gt;
</code></pre>
<img src="https://media.daily.dev/image/fetch/s--WAIMV_Lb--/f_auto,q_auto/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dr02xzgfjh4aw0m52p38.png?_a=BAMAMiWQ0" alt="open generative ui">
Pros: Lowest coupling possible. One tool on the backend covers infinite UIs. Disposable interfaces grounded in your data.
Cons: Unpredictable. Looks different every run. Sandbox is mandatory for security.
“Show me how electrons work.” “Give me a weird bar chart of my last 10 queries.” That kind of thing is useful here. You never wrote that component and you’ll never see it again.
live demo: <a href="https://opengenerativeui.copilotkit.ai/" target="_blank" rel="noopener nofollow">https://opengenerativeui.copilotkit.ai</a>
docs: <a href="https://docs.copilotkit.ai/generative-ui/open-generative-ui" target="_blank" rel="noopener nofollow">https://docs.copilotkit.ai/generative-ui/open-generative-ui</a>
<hr>
<h2>How does it support all patterns</h2>
All three levels need a way to stream events between the agent and frontend. That’s <a href="https://github.com/ag-ui-protocol/ag-ui" target="_blank" rel="noopener nofollow">AG-UI protocol</a>.
The agent sends events (“started”, “here’s a message”, “called a tool”, “state changed”), and the frontend reacts to them. Whether the agent is sending a controlled component, an A2UI schema, or raw HTML, it all travels through AG-UI the same way.
That’s why moving between levels in an AG-UI client (like CopilotKit) is a frontend change, not a backend rewrite.
So next time someone says “Generative UI” on your timeline, you can ask them which one. Hopefully this helps!
If you are interested in reading all of this in detail, check out the <a href="https://copilotkit.ai/blog/generative-ui-explained-how-agents-now-ship-their-own-interfaces" target="_blank" rel="noopener nofollow">blog</a> and try all three patterns live <a href="https://langgraph-py.examples.copilotkit.ai" target="_blank" rel="noopener nofollow">here</a>.

Anmol Baranwal

Generative UI is a spectrum of three patterns for how AI agents control UI: Controlled (agent picks from predefined components), Declarative/A2UI (agent selects from a schema-driven catalog), and Open-ended (agent generates raw HTML or controls external apps via MCP). Each pattern trades design control for flexibility. CopilotKit supports all three via the AG-UI protocol, which streams events between agent and frontend. The post demystifies the vague term and explains when each pattern is appropriate, with code examples for each approach.

Generative UI explained without the hype

I forgot to add it in the post but if anyone prefers watching, here is the 24min talk that covers all of this (code + live running examples): <a href="https://www.youtube.com/watch?v=a-K_qFUmda0" target="_blank" rel="noopener nofollow">https://www.youtube.com/watch?v=a-K_qFUmda0</a>
(which is where I learned most of it)

This sounds fun. I want to experiment with this at some point. These are the kinds of mature applications of generative AI that really prove the point that software is just going to continue to get more complex. And this whole hype around replacing developers is nothing more than just that. We will always outgrow the tools.

So much interesting!
One of the few takes on “Generative UI” that actually makes the term not feel marketing noise 👀

Once you see it that way, the conversation shifts from hype to trade-offs: determinism vs flexibility, safety vs expressiveness.