Generative UI makes the interface part of the agent runtime
Generative UI is moving agents beyond chat by making bounded, stateful interfaces part of the product runtime, with a concrete pilot path for PMs.
The product implication
Generative UI is moving the agent out of the chat transcript and into the product surface. The important shift is not that a model can emit a chart instead of a paragraph. It is that the model can propose a bounded interface, the renderer can turn that proposal into real controls, and the user can keep working through those controls without restating the same intent in natural language.
That makes the interface part of the agent runtime. A PM should evaluate it as a new execution boundary with its own state, permissions, latency budget, and failure modes, not as a visual formatting feature.
What changed
1. The research problem is now the interaction layer
The paper Software as Content: Dynamic Applications as the Human-Agent Interaction Layer names the underlying problem directly: linear chat is a poor fit for structured data, repeated parameter changes, and persistent task state. Its proposed Software as Content model lets an agent generate a task-specific application with filters, selectors, and triggers; the application persists and evolves across turns. The paper reports a working system evaluated across selection, exploration, and execution tasks, while explicitly keeping natural language for unexpected or nuanced intent. 1
The practical takeaway is narrower than “chat is dead.” Chat remains the flexible intent channel. Generated UI becomes the high-frequency control channel once the task has a stable shape.
2. The stack is separating transport from generation
The current protocol discussion is converging on two separate questions:
| Question | PM decision | Typical mechanism |
|---|---|---|
| Where does the experience run? | In your own product or inside someone else's host? | AG-UI for a frontend you control; MCP Apps for hosts such as ChatGPT, Claude Desktop, or Copilot. 2 |
| How much freedom does the model get? | Fixed components, composable catalog, or arbitrary code? | Static selection, declarative generation such as OpenUI Lang or A2UI, or open-ended HTML/CSS/JavaScript. 2 |
That separation matters because a team can keep one component policy while changing where the UI is delivered. A Japanese engineering blog's current overview of AG-UI, A2UI, and MCP Apps is telling for a different reason: the protocol names are now numerous enough that choosing the boundary is itself an architecture task. 3
3. Models are being trained to make UI decisions, not just format them
Macaron-A2UI treats generative UI as a model capability for personal agents. The authors train models to return natural language together with executable A2UI actions for collecting information, refining preferences, confirming choices, and organizing multiple goals. Their best reported result is 75.6 on A2UI-Bench without explicit schema hints; the training recipe combines LoRA-based supervised fine-tuning with reward-driven reinforcement learning and penalizes malformed or render-critical output. The paper also calls out latency as an unresolved issue when generation, validation, and rendering happen in real time. 4
This is useful evidence that the interface decision can be evaluated as a learned behavior. It is not evidence that a model is ready to control a production UI: the benchmark measures protocol and interaction quality under the paper's conditions, not reliability in your application.
4. The implementation path is becoming less expensive
A recent engineering walkthrough of OpenUI shows the practical shape. The developer defines a component library, generates the system prompt from that library, streams a compact OpenUI Lang response, and renders it with a client-side
Renderer. In the example, form state changes trigger a data tool directly; the system does not call the LLM again for every chart refresh. That is the key product pattern: let the model decide the initial interaction structure, then let deterministic tools own routine state transitions. 5OpenUI's own repository describes the same architecture as a renderer-agnostic core with framework bindings, component libraries, prompt generation, and progressive streaming. It reports that OpenUI Lang can use up to 67% fewer tokens than JSON, a vendor project claim that should be verified against your own payloads and model mix before it becomes a cost assumption. 6
Why PMs should care
The product problem it solves
Chat is efficient for expressing a new goal. It is inefficient for repeatedly adjusting a known one: changing a date range, comparing two segments, confirming a destructive action, or reviewing a set of ranked options. A generated interface can expose those operations once and preserve the user's working state.
That can improve three things at once:
- Interaction cost: users select, filter, and confirm instead of narrating every parameter.
- System cost: deterministic refreshes can avoid a fresh model call when only data or view state changes.
- Observability: the product can log which control was shown, selected, rejected, or revised, rather than treating the whole interaction as opaque text.
The tradeoff is that the UI becomes executable output. A malformed component tree, stale state binding, unsafe action, or inconsistent design token is now a product failure, not merely a bad answer.
The architecture decision
Use the least freedom that solves the workflow:
- Static components when the answer shapes are known and visual consistency is the priority.
- Declarative generation when users need varied layouts but the product must retain a typed component catalog, design tokens, and action policy.
- Open-ended generation only for isolated, exploratory artifacts where a sandbox can contain generated HTML, CSS, and JavaScript.
A useful rule is to make the model choose from a catalog, make the renderer validate the result, and make the action layer authorize every side effect. Do not let a successful render imply that an action is permitted.
The practitioner signal supports this direction but does not prove production maturity. Rabi Shanker Guha, CEO of a generative UI API company, described OpenUI as "literal React for agents." React Native engineer ROFI separately described using OpenUI's style system while adapting a mobile interface. Both are implementation-level signals, not independent reliability evaluations. 78
For a clear technical explainer, the AI Engineer talk Beyond Components: Designing Generative UI for MCP Apps lays out the static, declarative, and fully generative spectrum and highlights sandboxing as the central constraint for generated code. It had 137,735 views when checked, which makes it a useful accessibility signal, not evidence of adoption or correctness. 9
Loading content card…
How to implement now
Start with one workflow where users repeat the same structured operation often. Incident triage, research review, analytics exploration, and approval queues are better pilots than a blank “build me any app” canvas.
- Write the component and action contract first. Define the small catalog the model may use: inputs, selectors, tables, charts, confirmation controls, and empty or error states. Give every mutating action an explicit permission and confirmation rule.
- Keep generation declarative. Have the model emit a typed or schema-validated description of the interface. Keep arbitrary code out of the default path; if an exploratory artifact needs it, isolate that subtree in a sandbox with no ambient credentials or application DOM access.
- Separate three kinds of state. Store view state such as filters in the UI, business state in the product backend, and agent context in the orchestration layer. Log transitions between them. A filter change should normally call a data tool, not regenerate the entire interface.
- Choose the delivery protocol by ownership. Use an in-product event stream when your team owns the frontend. Use a host-sandboxed app when the experience must travel into a third-party surface. Treat the generated payload as untrusted input at either boundary.
- Evaluate the interaction, not only the answer. Build a replay set covering normal tasks, missing data, stale data, malformed output, conflicting instructions, permission changes, and recovery after a failed action. Track task completion, time to first useful control, correction rate, action error rate, latency, token cost, abandonment, and escalation back to chat.
- Roll out behind a reversible gate. Start with read-only actions and internal users. Add writes only after the renderer, authorization layer, and audit trail have passed the same task suite. Keep a text-only fallback so a UI-generation failure does not strand the user.
The first PM decision is therefore not “Should we add generative UI?” It is: “Which repeated workflow is expensive to narrate, and what is the smallest governed interface that removes that repetition?” If the answer has a stable interaction shape, declarative generative UI is ready for a focused pilot. If it does not, keep the experience in chat until the product can define the state and action contract.
References
- 1
- 2State of Generative UI
openui.com
- 3Generative UI and the protocols behind it
tech.nri-net.com
- 4
- 5Building UI with OpenUI's dedicated language
acro-engineer.hatenablog.com
- 6
- 7
- 8
- 9
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.