Generative UI

Beyond the chat bubble

Generative UI means the agent's work shows up as real interface, not just text. When your Crew or Flow calls a tool, updates its state, or reasons about a problem, you decide what the user sees: a progress checklist, a recipe card, a chart, a whole assembled panel.

CopilotKit renders generative UI along a spectrum, from fully author-controlled (you decide every pixel) to agent-invented (the agent assembles the surface):

The tiers compose freely; a single app usually mixes them.

Controlled

You own the components. The agent chooses which to show and with what data. This is the most predictable tier and where most apps start.

Tool rendering

The agent calls a tool on the backend. You register a matching component on the frontend with useRenderTool, and CopilotKit renders it, streaming the arguments in as they arrive.

"use client";
import { useRenderTool } from "@copilotkit/react-core/v2";
import { z } from "zod";

useRenderTool({
  name: "generate_recipe",
  parameters: z.object({
    title: z.string(),
    ingredients: z.array(z.string()),
  }),
  render: ({ args }) => <RecipeCard title={args.title} ingredients={args.ingredients} />,
});

See Tool-Based Generative UI for the full walkthrough, including progressive rendering as arguments stream, and Backend Tool Rendering for tools your Crew or Flow executes server-side.

State rendering

Instead of reacting to a single tool call, render the agent's state as it changes. This is the right pattern for multi-step work: read the agent's working state with useAgent and paint it however you like.

"use client";
import { useAgent } from "@copilotkit/react-core/v2";

function TaskProgress() {
  const { agent } = useAgent({ agentId: "task_runner" });
  const steps = agent?.state?.steps ?? [];
  return <StepList steps={steps} />;
}

See Agentic Generative UI for streaming state from a Flow, and Shared State for editing that state from the UI.

Reasoning

When the model reasons before answering, that thinking renders in the chat automatically. No component to write. See Reasoning.

Declarative

The agent goes beyond picking a component: it assembles a surface by combining building blocks from a catalog you define. You still own the components (the agent can only use what is in your catalog), but the layout is the agent's.

This is A2UI. You register a catalog on the provider:

<CopilotKit runtimeUrl="/api/copilotkit" agent="assistant" a2ui={{ catalog }}>
</CopilotKit>

The agent then builds surfaces from that catalog — either dynamically (it designs the layout from the conversation) or from a fixed schema your backend fills with data. See A2UI for both modes and error recovery.

Open-ended

At the far end, the surface is invented outside your app entirely. For CrewAI this comes through MCP: tools served by an MCP server the agent connects to render as tool calls in the chat, the same way backend tools do. This is the least constrained and the least predictable tier.

MCP tool calls surface as standard tool-call UI — render them with useRenderTool like any other tool. Full agent-invented "MCP App" surfaces are an emerging capability; see the CopilotKit docs for the current state.

Related