A new wave of “agent-native app framework” projects has been showing up in trending lists this week, and the term that keeps recurring is generative UI — worth explaining on its own since it’s a genuinely different output than everything else I’ve covered this month.
Every agent I’ve written about so far outputs one of two things: text, or a file on disk — a chat response, a code diff, a written report. Generative UI is a third category: instead of describing an answer in words, the agent constructs an actual interface — a form with the right input fields, a chart shaped for the specific data involved, a set of buttons matching the specific choice being offered — generated fresh for that exact response rather than pulled from a template someone built in advance for that scenario.
The mechanism, in plain terms: rather than the model outputting plain text or committing to a fixed, pre-built layout, it outputs structured data describing an interface — which components to render, what data populates them, how they’re arranged — and a rendering layer on the receiving end turns that structured description into an actual, interactive UI. The model isn’t drawing pixels; it’s deciding what kind of interface the current answer calls for and describing that choice in a structured format built for exactly this purpose, similar in spirit to how MCP gives an agent a standard way to describe a tool call rather than inventing an ad-hoc format each time.
Why this is a meaningfully different capability than just formatting text nicely: a chat interface answering “compare these three pricing plans” can give you a nicely formatted table in Markdown, but it’s still one fixed shape decided by whoever built the chat interface, applied to every kind of answer the same way. A generative UI agent can decide a comparison table fits this specific question, while a different question in the same conversation gets a form, or a set of selectable cards, or an interactive chart — each shape chosen because it fits the specific content, not because it’s the one shape the interface was built to always produce.
Where this connects to something I’ve already covered: it’s the same instinct behind spec-driven development, just applied to visual output instead of code — a structured, explicit intermediate representation instead of a model directly producing something less reliably reviewable. A written spec makes a code change reviewable in a paragraph before it’s a diff. A structured UI description makes an interface auditable as a data structure before it’s rendered pixels, which matters for exactly the reason prompt injection matters elsewhere: a structured, constrained description is much harder to hijack into something unintended than an agent given free rein to emit arbitrary rendering code.
The honest limits worth naming: generative UI depends entirely on the rendering layer actually supporting whatever component the model calls for — a model can describe an ideal interface that the receiving app has no way to actually render, the same ceiling any generated content hits against whatever’s actually able to consume it. And a UI generated fresh for one specific answer doesn’t carry the design consistency a hand-built interface gets from being used and refined across thousands of sessions — it optimizes for fitting this exact answer, not for feeling identical to the last five things you looked at in the same app.
