Generative UI

Problem

A hardcoded interface can only render the response shapes its developers anticipated, so every new agent capability — a new card type, a new interactive step — needs a coordinated frontend release before users can see it. Pushing the raw model output to a generic chat bubble avoids that coupling but throws away structure: the client receives text and cannot tell a chart from a form from a confirmation prompt, and cannot route an interactive step like a button click back into the agent. Embedding model-generated executable code in the page removes the limit but opens an injection surface the team cannot audit.

Solution

Specify an event vocabulary that carries declarative interface structure (component, props, layout), shared state, and interaction requests rather than raw markup or code. The agent emits these events on the same stream as its text; a generic client renderer maps each declared component to a real widget and routes user interactions (clicks, form submits) back to the agent as new events. Because the contract is the protocol, the same frontend works against any agent backend that speaks it, and the agent can introduce new interface shapes without a frontend release. Declarative payloads (for example JSON Lines describing the component tree) keep the surface auditable; executable payloads are avoided unless sandboxed.

When to use

• The agent's output is open-ended and a fixed set of response shapes cannot capture it.
• Frontend and agent backend are owned by different teams or released on different schedules.
• Interactive steps (forms, confirmations, button choices) must flow back into the agent loop.
• The interface should be swappable across multiple agent backends behind one protocol.