The generative UI ecosystem

At first glance the generative UI ecosystem is a crowd of competing tools with overlapping names. It reads more clearly as three layers that solve different problems. Most products pick from more than one, so the question is rarely which tool wins. It is which layer you need.

This page maps the roles, not the leaderboard. Specific versions, adoption, and funding move from month to month. What follows is the shape of the field, which changes more slowly.

The three layers

A generated interface has to be described, carried, and drawn. The ecosystem has split along those lines.

A transport carries the stream of events between an agent and the front end: a tool was called, the state changed, the turn ended. It does not say what the interface looks like. AG-UI is the common one, and several agent frameworks speak it.

A declarative payload describes the interface as data, so the client can draw it from a catalog of components it controls. The model returns a specification, not markup, which keeps the result on brand, accessible, and safe by construction. Google’s A2UI, Vercel’s json-render, and Thesys’s OpenUI Lang all take this shape, as do older server-driven formats like Microsoft’s Adaptive Cards.

A sandboxed app is a third-party interface that appears inside someone else’s assistant. The vendor ships a component that the host runs in a sandbox. MCP Apps, an extension to the Model Context Protocol, is the standard here, with roots in the earlier MCP-UI project.

These compose rather than compete. A product might draw its own screens from a declarative payload, expose a third-party surface through MCP Apps, and use a transport like AG-UI as the pipe between the agent and the page.

Layer	What it does	Examples	Reach for it when
Transport	Carries agent-to-UI events	AG-UI	An agent drives the interface and you need its events
Declarative payload	Describes UI as data, drawn from a catalog	A2UI, json-render, OpenUI Lang, Adaptive Cards	You compose your own screens from your own components
Sandboxed app	A third-party UI inside an assistant	MCP Apps, MCP-UI	Your interface has to appear inside Claude, ChatGPT, or similar

Frameworks

Protocols define the wire; frameworks give you something to build with. They tend to wrap one or more of the layers above and add the client-side pieces: the chat surface, the component rendering, the state handling.

• CopilotKit spans the whole range, from mapping tool calls to components, through declarative catalogs, to open-ended sandboxed UI. It also maintains AG-UI.
• Vercel’s AI SDK provides the streaming and tool plumbing, with json-render as its declarative layer.
• assistant-ui offers composable chat primitives and tool renderers for React.
• Flutter’s genui brings the catalog approach to Dart, using A2UI as its format.
• Thesys sells a hosted API that turns model output into a catalog-constrained interface.

The set changes often, and tools arrive and retire, so treat any list as a snapshot. The durable point is that a framework is a convenience over the layers, not a fourth layer.

Design-time tools are a different thing

Some of the best-known names, v0, Lovable, and Bolt, are not runtime generative UI at all. They generate interface code at design time, which a developer reviews and ships. The output is a pull request, the same for everyone who then uses the product. That is AI-assisted development, and it is often confused with generative UI because both use a model to produce UI. The comparisons page separates them.

The assistants compose their own

The largest deployments are not built on any public protocol. The frontier assistants compose interactive answers natively: Google’s Gemini generates a custom view per prompt, OpenAI’s ChatGPT assembles answers from a library of components, and Claude renders artifacts and, through MCP Apps, the interfaces of connected tools. These are proprietary and expose no wire format, but they are where most people first meet generative UI.

The line that runs through all of it

One distinction cuts across the whole ecosystem: whether the model returns a specification drawn from a catalog, or writes the interface code itself. The first is the schema-driven approach (A2UI, json-render, Thesys, Adaptive Cards); the second is code generation (Gemini’s per-prompt view, Claude’s artifacts). The schema-driven approach is becoming the default for interfaces real customers see, because the output stays inside components someone already reviewed. What is generative UI and how to build it go into why.

A naming trap: OpenUI and Open UI

Three different things share the name, and search engines and assistants routinely confuse them. OpenUI, at openui.com, is Thesys’s runtime system for generating interfaces from a component catalog. A separate open-source project, wandb/openui, is a design-time tool that turns a prompt into rendered code. And Open UI, at open-ui.org, is a W3C community group standardizing web platform controls, with nothing to do with AI. If you are reading about “OpenUI,” check which one.

How to read it

Most teams building their own product need the declarative layer: a catalog of components and something to draw them. Reach for a sandboxed app when your interface has to live inside an assistant you do not own, and for a transport when an agent is driving the screen and you need its events. Whichever you choose, the interface is only as good as the state behind the decision, and a generated interface is hard to improve if you cannot measure it. Measuring generative UI covers the part the ecosystem has been slowest to solve.