How to build generative UI

A generated interface has three parts. Build them in this order and each one has a clear job.

1. State: a current picture of the visit

State is what the decision reads: pages seen in the last few minutes, the last action and how long ago, items viewed, a search that returned nothing, a basket left idle. It has to be current to the last few seconds and available to read on the request, before the page renders.

This is usually the hard part. Batch data, a segment computed overnight, describes who the visitor was yesterday, not what they are doing now. Building generative UI on batch state produces a layout for the wrong person. Teams either build a low-latency store for session state themselves or use a tool made for it. Snowplow Signals is one such tool: it computes attributes from behavioral events as they happen and serves them to the application in a few milliseconds. Whatever you use, the requirement is the same: the state has to be fresh and fast to read.

2. Decision: choosing what to render

Something has to turn the state into a choice of components. There are three common ways, in rough order of flexibility:

• Rules. Code maps state to components. Predictable, easy to test, and every new case is a new rule to write.
• A model choosing from a catalog. A model reads the state and returns a specification naming components you built. It handles cases no one wrote a rule for, and the output stays inside your catalog.
• An agent. A model reasons over the context on each request and returns the layout. An agent with no grounding guesses; given a current, structured picture of the visit, it can compose a screen that fits. The interesting work is less the model than the context you feed it.

Most teams start with rules and move parts of the decision to a model as the cases multiply.

3. Render: drawing the chosen components

The decision produces a description of the screen. A renderer turns that into the interface, using components the client already ships.

json-render, a library from Vercel, is a common choice. You describe a catalog of your own components and their props. A model returns a JSON specification that references only those components, and json-render draws the result. The model never writes markup, so the page cannot contain anything you did not ship.

json-render is one of several ways to move a decision to a screen, and the wider set sorts into three layers. A declarative payload describes the interface as data for the client to draw: json-render, Google’s A2UI, and Thesys’s OpenUI Lang all take this shape. A transport carries that payload, and the events around it, between an agent and the front end; AG-UI is the common one. And for an interface that has to appear inside someone else’s assistant, MCP Apps ships a sandboxed component the host renders. Most customer-facing generative UI needs only the first layer, a catalog and a renderer. The others matter when the interface lives inside an agent or another company’s product.

One reason the catalog approach dominates for real customers is that it inherits the qualities of the components it draws from. If your components are accessible and on brand, every generated screen is too, because the model only arranges them. An interface built from model-written markup has no such guarantee; each screen is new code that nobody reviewed. That is the practical case for constraining the output to a catalog, beyond security.

The split matters: json-render draws, it does not decide. Something upstream still chooses what goes in the specification, and that choice is only as good as the state behind it.

Putting it together

A typical request flows through all three parts:

1. The server reads the current state for the visit.
2. A rule, a model, or an agent turns that state into a specification of components.
3. The renderer draws the specification into the screen the visitor sees.

Two practical limits hold the whole thing together. The decision has to return within the request, so the state read and the decision step both have to be fast. And the output has to stay inside the components the client can render, so a typed contract or a fixed catalog keeps the decision honest. Get those two right and the rest is tuning the rules and the data that drive generation.