The Interface Is Now an Output: OpenUI, Generative UI, and What Changes When Software Draws Its Own Screens

For the whole history of software, the screen was designed before the user arrived. Generative UI changes that: the model produces the interface at runtime, as structured components rather than text, in response to what the user actually asked. OpenUI is the open standard trying to make that output portable across models and frontend frameworks. It is a small project with a large implication, and it rhymes with everything the big platforms shipped this autumn: Salesforce's AIforce assembling interfaces over governed data, Code in Microsoft's new Copilot building apps from a prompt, Slack's Slackforce Surfaces drawing dashboards in a channel. The open-source version matters because it shows the mechanism underneath all of them, and because a company can run it on its own data without buying a platform. This post explains what generative UI is, what OpenUI adds, where it belongs in a business and where it does not, and what it changes about cost, lock-in, and governance for the people paying for software. Further down there is a sandbox you can type into.

What is generative UI?

Generative UI means the interface is generated by an agent at runtime rather than built ahead of time. Ask an assistant for a portfolio summary and, instead of a paragraph you have to read, you get a table, a chart, and two buttons, assembled for that question. The components are real and interactive; the arrangement was decided a moment ago.

The idea has been around in research for a while; a Google Research paper from November 2025 made the case that language models are effective UI generators. What was missing was a practical way to let a model describe an interface safely and cheaply, and to render that description in whatever frontend a company already runs. That is the gap OpenUI targets.

What does OpenUI actually do?

OpenUI is an open-source, MIT-licensed generative UI framework maintained by Thesys. It covers the whole path from model to screen, works with more than one frontend framework, and has a small language at its center, OpenUI Lang, designed to be compact and to stream. Three design choices explain it:

• The model writes a UI language, not JSON or HTML. Instead of asking the model for JSON or Markdown, OpenUI has it answer in a declarative UI language, and each line maps to a component from your own library, rendered safely on the client. The model names components and properties; your code decides what those components are and how they render. The model never emits raw HTML or script, which is the security property that makes the whole idea deployable.
• It streams. The format is designed so the interface renders progressively as the model produces it, the way text streams today, rather than waiting for a complete response.
• It is compact. The project's own benchmarks put OpenUI Lang at up to 67% fewer tokens than JSON for the same interface, and about half as many on average, which matters because every generated screen is paid for by the token.

Around that core, the project ships runtimes for React (the most complete), Vue, Svelte, and Angular, a CLI that scaffolds an app and generates a system prompt from your component library, and stream adapters for common formats and agent frameworks (OpenAI's APIs, the Vercel AI SDK, LangGraph, and AG-UI), so it works with any model provider. The practical workflow: you define the components a model is allowed to use, the tooling teaches the model that vocabulary, and the model composes interfaces from it. The broader ecosystem has settled into a recognizable stack, with transport protocols such as AG-UI and MCP Apps carrying generated UI into a frontend, and generation formats such as OpenUI, A2UI, and json-render describing it.

Why is the world converging on this?

Because three separate pressures point the same way.

Answers are becoming actions. When an agent can act, a text reply is the wrong shape. "Here are the three invoices that need approval" wants three rows and an approve button, not a paragraph and a follow-up prompt. Generative UI is how agents hand control back to a person at the moment it matters.

Fixed screens cannot keep up with what people ask. Every enterprise application has a long tail of questions its designers never anticipated. A generated interface answers the question that was asked, in the shape it needs, without a product roadmap item for each one. That is the thesis behind AIforce, Code in Copilot, and Slackforce Surfaces, and the thesis of our post on the interface paradigm shift.

Tokens and trust both favor structure. A constrained UI language is cheaper to generate than prose and safer to render than HTML. Structure is what lets a company allow the model to draw screens at all.

The open-standard part matters for a reason business readers will recognize: if the interface is going to be an output, companies want that output to be portable across models and frameworks rather than locked to one vendor's platform. OpenUI is a bet that the language of generated interfaces should be open the way HTML was.

Where does generative UI belong in a business, and where does it not?

This is the question that decides whether a company gets value or sprawl, and it is the same balance question we keep returning to.

Where it pays: low-frequency, analytical, one-off work. Internal questions that today end in a spreadsheet export. Agent results that need a decision from a person. Portfolio, pipeline, and operations views that change with the question. Customer support surfaces where the right next step varies.

Where to keep a designed screen: high-frequency work people do a hundred times a day, where muscle memory is the productivity. Regulated workflows where the layout, the fields, and the audit trail are part of compliance. Anything customer-facing where brand and consistency are the product. Nobody wants their loan application to look slightly different every time.

The failure mode to design against: generated sprawl. Fifty people asking for fifty slightly different dashboards, each computing a metric its own way, with no shared definitions underneath. Generative UI amplifies whatever data layer sits beneath it, which is why our view is that the governed record comes first and the generated screens second; we made the argument for lending in the loan is the same, the data is not and for manufacturing in one record of the machine.

What does this mean for the business paying for the software?

Four things, and none of them require taking a side on which framework wins.

The cost of a screen is changing shape. A designed screen costs design and engineering time up front and nearly nothing per use. A generated screen costs almost nothing up front and a few cents of tokens every time someone asks. That inverts the economics for the long tail: the hundred questions that never justified a product ticket can now have an interface, and the ten screens everyone uses all day should stay designed, because paying tokens on every load for a fixed workflow is the expensive way to do a cheap thing. Budget accordingly: generative UI is an operating cost that scales with questions asked.

Lock-in now lives in the interface layer. When Salesforce assembles your screens inside its estate and Microsoft builds your apps inside its tenant, the generated interface is portable only as far as the platform allows. An open standard such as OpenUI is the counterweight: a company can define its own component library, run the generation against any model, and render in whatever frontend it already owns. For a business that has spent two decades avoiding being captured by one vendor's UI, this is the same decision in a new place, and worth making deliberately rather than by default.

The component library becomes a governance surface. Whatever vocabulary you give the model is exactly the set of things it can show and the actions it can offer. That makes the library the place where brand, accessibility, compliance, and permissions get enforced once, instead of in every generated screen. A twenty-component library reviewed by design, security, and legal is a smaller, stronger control than any policy document, and it is where a serious program should start.

Frontend teams change jobs, not headcount. Building a screen per request becomes building and maintaining the vocabulary that screens are made from, plus the evaluation that generated interfaces are correct. That is a more valuable job and a different one, and teams should plan the transition rather than discover it.

The honest summary for a leadership team: generative UI is real, cheap at the margin, and arriving inside every platform you already pay for. The decisions that matter are which workflows keep a designed screen, which vocabulary the model is allowed, and whether your generated interfaces will belong to you or to a vendor. Those are audit questions before they are engineering questions, and they are the ones we work through with clients before anyone builds.

Try it: a generative UI sandbox

The box below is a small simulation of the idea on this page. There is no model behind it and nothing leaves your browser. You type a tiny declarative spec, the kind of thing a model would stream, and the page renders it as live components from a fixed library. The presets show what an agent might produce for a few business questions, streamed in the way a real response arrives. The point is the mechanism: a constrained language in, real interactive components out, and nothing the text can do except compose the pieces you allowed.

A few things to notice while you play. The spec is readable by a person, which is what makes it reviewable. The renderer refuses anything that is not in its component list, which is the security model in one line. And the interface changes shape with the question, which is the whole idea.

What we would tell a product team this quarter

1. Define the component library first. The value and the safety both come from the vocabulary you allow. Twenty well-designed components beat an open-ended renderer.
2. Put it behind an agent that already works. Generative UI is a presentation layer for agent results, not a reason to build an agent.
3. Fix the data definitions before the screens multiply. A generated dashboard is only as honest as the metric underneath it.
4. Start internal. The first wins are inside the company, where sprawl is survivable and feedback is immediate.
5. Keep the escape hatch to a designed screen. When a generated interface becomes the one people use every day, that is the signal to design it properly.

We build agent products and the interfaces around them for clients on whatever stack they run, and we are not affiliated with OpenUI or Thesys; we find the standard genuinely useful and expect to use it where it fits.

Sources: the OpenUI project README and documentation (github.com/thesysdev/openui, openui.com); Thesys Engineering, "The State of Generative UI in 2026: Transports, Formats, and Tradeoffs" (June 2026) for the ecosystem map; Leviathan et al., Google Research, "Generative UI: LLMs are Effective UI Generators" (November 2025). Project claims such as token efficiency are the project's own. As of October 16, 2026.

Related reading: The screen is optional now · Slackforce Surfaces explained · What is WebMCP? · AI agent development