useChat. This page is your map of the Building agents section — what each part does, how a single message flows through them, and which page to open next.
Follow one message
A single turn moves through all three parts in order:- The frontend transport sends the user’s message to the session’s inbound stream (
.in). - The agent task wakes on the new message, runs your turn loop, and streams the model’s response into the session’s outbound stream (
.out). - The frontend transport reads
.outand renders tokens intouseChatas they arrive.
.out even if the browser reloads mid-stream.
The three parts
The agent task
chat.agent() is the code you write: a long-lived agent whose run function is the turn loop. Messages arrive accumulated, you call streamText, and the returned stream is piped back to the frontend for you. Tools the model can call and lifecycle hooks that fire around each turn both hang off the same config. See Backend for the full chat.agent() surface.
The session
The conversation lives in a session, not in the task’s memory: a pair of durable streams —.in and .out — keyed on your chatId. Because the session is durable, a conversation survives page refreshes, deploys, and the run boundaries between turns. The task can restart and pick up the same session. How it works covers the mechanics of what survives and why.
The frontend transport
One hook —useTriggerChatTransport — connects the Vercel AI SDK’s useChat to the agent’s session. There are no API routes to write: the transport talks to the session directly using a scoped token. See Frontend for wiring, tokens, and starting sessions.
An annotated agent
Everything above maps onto one task:trigger/my-agent.ts
Related pages
Beyond the three core parts:
Features covers opt-in capabilities (Head Start, compaction, steering, actions), and Patterns covers production recipes (sub-agents, HITL approvals, persistence, recovery).

