Generative UI
How CopilotKit lets agents drive UI — the primitives it ships, what each one is for, and how to pick the right one.
Generative UI in CopilotKit is the set of primitives that let an agent decide what appears on the screen — from rendering a specific application component you've built, to composing layouts from a catalog, to embedding sandboxed UI shipped by an MCP server.
What CopilotKit ships#
Six primitives. Each one solves a different problem.
| Primitive | What it does |
|---|---|
| Components as Tools | Register an application component as a frontend tool; the agent calls it and CopilotKit renders it inline with typed inputs. |
| Tool Call Rendering | Map your agent's existing backend tool calls to custom UI cards showing live status, arguments, and results. |
| State Rendering | Subscribe to the agent's streamed state and re-render UI as values arrive. |
| Reasoning | Render the model's reasoning tokens inline as a first-class message type (default card, or fully custom). |
| A2UI | Render UI from a declarative schema the agent emits, composed against a catalog you register. Two flavors: Dynamic Schema (LLM generates the schema) and Fixed Schema (you author the schema, agent supplies data). |
| MCP Apps | Embed UI that an MCP server ships alongside its tools, rendered in a sandboxed iframe. No frontend renderer required. |
Angular API#
Pass a standalone Angular component to registerFrontendTool when the tool
runs in the browser. Use registerRenderToolCall when the tool runs on the
backend and Angular only controls how the call appears.
Prefer to learn by building? Follow Frontend tools and generative UI for a complete Angular example with typed tools, standalone renderer components, A2UI, Open Generative UI, and MCP Apps.
Pick one#
Match the row that sounds like your situation:
| You want to… | Use |
|---|---|
| Let the agent render a specific application component you've already built | Components as Tools |
| Brand the cards CopilotKit draws for your agent's existing backend tools | Tool Call Rendering |
| Update UI as the agent's state changes (progress, drafts, dashboards) | State Rendering |
| Surface the model's thinking chain in the chat | Reasoning |
| Let the agent compose layouts from a catalog you define | A2UI — Fixed Schema if the surface is known, Dynamic Schema if it isn't |
| Embed someone else's MCP-hosted UI in the chat | MCP Apps |
How the primitives compare#
These primitives sit along a spectrum from author-controlled to agent-invented. Same frontend application, same runtime, same AG-UI protocol — the choice is per-feature, not per-product.
- Controlled — you wrote the component; the agent only picks which one to render and what data to pass. Highest predictability, highest engineering cost per capability. Components as Tools, Tool Call Rendering, State Rendering, Reasoning.
- Declarative — the agent emits a structured spec; the frontend composes from a catalog you registered. Creativity inside a guardrail. A2UI (Dynamic and Fixed Schema).
- Open-Ended — the UI is invented elsewhere (an MCP server) and you sandbox it. Highest expressive range, hardest to guarantee accessibility / brand / security. MCP Apps.
Where to go next#
Components as Tools
Register an application component as a tool the agent can call.
Tool Call Rendering
Custom UI for your agent's backend tool calls.
State Rendering
UI that re-renders as the agent's state streams in.
Reasoning
Render the model's reasoning tokens inline.
A2UI
Declarative UI from an agent-emitted schema.
MCP Apps
Embed MCP-hosted UI in a sandboxed iframe.