Generative UI: The Technology Landscape for AI-Generated Interfaces
A current guide to A2UI, AG-UI, MCP Apps, constrained component systems, and code-generating workspaces—and the different problem each approach solves.
Generative UI is becoming a stack rather than a single technique.
An agent may generate a declarative description that a trusted client renders, stream state and tool events to a frontend, return an interactive app inside a conversational host, or write complete interface code for a person to review. These approaches are often grouped together, but they solve different problems and create different trust boundaries.
The most useful way to understand the landscape is to ask three questions:
- Who decides which components may appear?
- What travels between the agent and the interface?
- Is the result rendered at runtime or reviewed as code first?
The landscape at a glance
| Approach | Primary job | Main strength | Main trade-off |
|---|---|---|---|
| A2UI | Describe an interface as declarative data | Native rendering with client-controlled components | Limited to the client's available catalogue |
| AG-UI | Connect an agent backend to a user-facing frontend | Streaming messages, state, tool calls, and interaction events | It transports interaction; it does not define the full visual system |
| MCP Apps | Embed an interactive app inside an MCP host | Rich tools remain inside the conversation context | HTML runs in a sandbox and host support varies |
| Constrained component systems | Map generated structured data to a known component set | Predictable brand and behaviour | Less freedom than arbitrary code |
| Code-generating workspaces | Produce editable interface code or artifacts | Maximum flexibility and rapid prototyping | Generated code still needs review, testing, and deployment discipline |
A2UI: declarative interfaces across a trust boundary
A2UI is an open declarative protocol for agent-driven interfaces. The agent sends structured messages describing interface elements and data; the client renders them using its own native components.
The distinction is important. The model is not sending arbitrary JavaScript for the client to execute. The client controls the component catalogue, security policy, styling, and platform-specific behaviour. The same intent can therefore be represented with web, mobile, or desktop widgets while remaining consistent with the host application.
A2UI is useful when:
- an agent is remote or crosses an organisational trust boundary;
- the host needs strict control over available controls;
- interfaces should stream progressively;
- native styling and accessibility matter more than arbitrary layout freedom.
The protocol is under active development, so production teams should use the current specification rather than copying a version number from an article.
AG-UI: the event stream between agent and frontend
AG-UI is an open, event-based protocol connecting agentic backends to user-facing applications. It standardises the flow of messages, tool calls, state changes, lifecycle events, and user interactions.
AG-UI and A2UI are complementary:
- AG-UI can carry the interaction and state stream.
- A2UI can describe interface widgets within that stream.
This separation is useful because an agent interaction is longer-lived than a normal request and response. It may stream partial output, pause for approval, invoke a tool, update shared state, recover from an interruption, and continue after user input.
AG-UI provides common events for those behaviours without requiring every frontend and agent framework to invent its own transport contract.
MCP Apps: interactive tools inside the conversation
MCP Apps extends the Model Context Protocol so a tool can reference an interactive UI resource. A compatible host renders that resource in a sandboxed iframe and mediates communication between the app, the conversation, and server tools.
This approach fits experiences that are awkward as text:
- charts and explorable data;
- multi-step forms;
- configuration panels;
- approval workflows;
- media viewers;
- live progress or monitoring.
Unlike A2UI, an MCP App can contain a complete HTML interface rather than only requesting native components from a catalogue. The sandbox, content security policy, capability negotiation, and host permissions therefore become central to the security model.
MCP Apps are best treated as progressive enhancement. A tool should still return a useful text or structured-data result when its host cannot render the app.
Constrained components and generated code
Some teams do not need an interoperability protocol. They need a reliable way for a model to choose from components inside one product.
Projects such as Vercel's json-render let developers define a component catalogue and schema, then render generated structured data through those known components. This offers many of the safety and consistency benefits of a declarative protocol with a smaller application-specific surface.
At the other end of the spectrum, tools such as v0, Claude Artifacts, and OpenAI Canvas generate or edit actual code and documents in a dedicated workspace.
Code generation is valuable for prototyping and developer-led workflows because the output can use any component or layout the environment permits. It also moves responsibility downstream: humans still need to review dependencies, accessibility, security, data handling, performance, and maintainability.
Choose by trust and lifecycle
The correct approach depends less on novelty than on where the interface lives.
Use a declarative catalogue when the interface is generated at runtime for end users and the host must retain control. Use an event protocol when an agent and frontend need a durable, stateful connection. Use an embedded app when an existing tool needs a rich interface inside a conversational host. Use generated code when a developer or designer will review and own the result.
Hybrid systems are normal. An AG-UI event stream can transport A2UI messages. An MCP tool can return structured data when UI support is absent. A developer can use generated code to create the stable component catalogue that a runtime model later selects from.
What remains difficult
Protocols do not remove the product-design work. Teams still need to decide:
- how generated interfaces preserve focus and avoid layout shifts while streaming;
- how users understand what was generated and from which data;
- how state, validation, undo, and approval work;
- how every permitted component meets accessibility requirements;
- what happens when output is incomplete or invalid;
- which decisions must remain deterministic.
Our companion guide, Generative UI: How AI Is Changing Static Interfaces, covers those design boundaries in more detail.
Why POCKLA researches this
POCKLA's 2025 funding round supported earlier work on AI-powered content and adaptive experiences. That research still informs the agent-operated systems behind the company.
POCKLA's current commercial offer is different: a managed consumer lead-generation service in which buyers pay per qualified lead. Generative UI is a technical research area, not a separate software product POCKLA is currently selling.
Looking for the current POCKLA service? See how POCKLA supplies qualified leads →