RSC Generative UI
Purpose and Scope
AI SDK RSC is the React Server Components-oriented way to build generative user interfaces: instead of only streaming text tokens into a chat bubble, server-side code can stream React component output to the client. The official AI SDK RSC docs frame this as experimental and recommend AI SDK UI for production. That status matters when choosing an architecture. RSC can be useful when a Next.js application already depends on React Server Components and Server Actions, while the newer UI packages are the safer default for cross-framework streaming chat, message persistence, transport customization, and production support.
The nearest repository-backed UI evidence for this page documents the newer AI SDK UI pattern used by harnesses: a client uses useChat(), a server route streams output, and the stream is compatible with UI message streams. That source is useful because it shows the production-oriented model that RSC should be compared against. In the UI path, the client works with messages and parts, while server code resumes or creates a session and returns a UI message stream. RSC, by contrast, centers the server-rendered component stream and AI/UI state model. Sources: content/docs/03-ai-sdk-harnesses/07-ui.mdx
Relevant Source Files
content/docs/03-ai-sdk-harnesses/07-ui.mdx- Documents how AI SDK harness streams integrate with AI SDK UI message streams, includinguseChat(),DefaultChatTransport,HarnessAgentSessionsession resumption, and conversion between model messages and UI message streams. This is the source-backed comparison point for explaining how the newer UI approach differs from RSC.
Core Concepts
React Server Components are components rendered on the server and streamed to the client. In AI SDK RSC, that capability is combined with Server Actions, which let client-side interactions call server-side functions with type safety. The result is a generative UI model where an LLM-backed server action can decide what UI to return, and the client can receive progressively streamed React output rather than waiting for a full response. This is most relevant when the unit of generation is interface structure, not just text.
The central primitive in the RSC documentation is streamUI, which represents the “generate UI on the server and stream it to the browser” workflow. In a typical RSC mental model, the model call can produce text, call tools, and cause server-rendered UI fragments to appear as the response progresses. Shared AI/UI state is the companion concept: AI state is the conversation or model-facing state the server needs, while UI state is the React-facing state rendered for the user. Keeping that distinction clear prevents leaking presentation details into model prompts or losing the data needed to restore a session.
AI SDK UI uses a different abstraction boundary. The harness UI documentation shows the client rendering messages returned by useChat(), iterating through message parts, rendering text parts inline, and treating tool or dynamic-tool parts as structured data. The client transport is explicitly configured with DefaultChatTransport pointed at /api/chat. Instead of streaming React component trees, this flow streams UI message parts that framework packages can render in a consistent way. Sources: content/docs/03-ai-sdk-harnesses/07-ui.mdx
RSC Versus AI SDK UI
Choose RSC when the experiment is specifically about server-rendered, streamed React components and the application is already aligned with React Server Components. The official docs describe RSC as compatible with frameworks that support React Server Components, and the main benefit is going beyond text into streamed UI. That is different from simply building a chatbot. A chatbot can be implemented as text and structured message parts; a generative UI experience may ask the model to select, compose, or progressively reveal actual interface elements from server code.
Choose AI SDK UI when the application needs the newer, production-recommended message-stream architecture. The repository-backed harness UI guide emphasizes that harness streams are compatible with AI SDK UI message streams and that useChat() can consume server route output. It also calls out a critical state-management difference for agent or harness-backed chats: a harness owns its conversation state, so the route should resume or create a HarnessAgentSession for the chat id instead of replaying the whole UI message history into a model. Sources: content/docs/03-ai-sdk-harnesses/07-ui.mdx
That session distinction is a practical migration signal. In RSC examples, state management is often explained as managing AI state and UI state for a server-component experience. In newer UI examples, the durable boundary is usually a chat id, persisted messages, stream resumption, and server routes that return UI message streams. For harnesses, the source explicitly recommends persisting the opaque resume state returned by session.detach() and using durable storage instead of an in-memory map in production. That pattern is closer to a transport/session architecture than an RSC component-stream architecture. Sources: content/docs/03-ai-sdk-harnesses/07-ui.mdx
Execution Flow
A useful way to reason about the RSC flow is server action first. The user triggers an action, the server calls the model, and streamUI streams React output as the model response unfolds. The UI can show loading states, streamed component updates, and generated interface fragments. AI state records the information needed for model continuation, while UI state records what React should render. Saving and restoring state means persisting enough information to reconstruct the user-visible interface and the model-facing context without assuming that transient server execution will remain alive.
The source-backed AI SDK UI flow is route and message first. The client calls sendMessage({ text: input }); useChat() tracks messages, status, and transport state; the route receives the request; server code resumes or creates the harness session; and the route converts between UI messages, model messages, harness output, and a UI message stream response. This is a strong default for applications that need conventional HTTP routes, resumable sessions, and framework-neutral rendering. Sources: content/docs/03-ai-sdk-harnesses/07-ui.mdx
import { useChat } from '@ai-sdk/react';
import { DefaultChatTransport } from 'ai';
const { messages, sendMessage, status } = useChat({
id: 'example-chat',
transport: new DefaultChatTransport({ api: '/api/chat' }),
});Implementation Details and Guardrails
When building with RSC, treat generated components as a server-rendered interface layer, not as a replacement for clear application state. Keep model-facing state serializable and intentional, define what data belongs in AI state, and keep UI-only concerns out of prompts unless the model genuinely needs them. Because the official docs mark AI SDK RSC as experimental and recommend AI SDK UI for production, production systems should have an explicit reason to remain on RSC, such as a React Server Components-specific experience that cannot be represented well as message parts.
When building with the newer AI SDK UI path, follow the source’s session guidance. Do not replay an entire UI message history into an agent or harness when the harness already owns the conversation. Resume or create the session for the chat id, persist the detached resume state, and use durable storage in production. This protects long-running tool loops, approval pauses, and interrupted turns because the resume state carries continuation information internally. Sources: content/docs/03-ai-sdk-harnesses/07-ui.mdx
Next Steps
If you are starting a production chatbot or agent interface, continue with AI SDK UI pages on chatbots, message persistence, resume streams, transports, and tool usage. If you are evaluating RSC specifically, read the RSC docs on streaming React components, managing generative UI state, saving and restoring states, loading states, error handling, authentication, and migrating from RSC to UI. For harness-backed systems, pair this page with the workflow and harness references so the server route, session store, sandbox identity, and UI message stream all line up before adding more complex tools or approvals.