Chat

Chat is where you hand work to a published Agent and watch it happen. Pick an Agent, start a session, and every run streams back live — what the Agent said, what it did, and anything it needs from you before it can continue.

Starting a session

The "New chat" picker is searchable and lists every published Agent in the workspace, each with a resolved-model chip — or, for an Agent whose build hasn't finished, a Building… or Build failed status in place of the chip. Picking an Agent opens a new thread that targets its currently published version and pins that version for the session's life: republishing the Agent later never moves a thread that's already running.

Sending the first message puts you in the thread immediately — your message renders while the session is still being created, rather than holding the composer until the server answers. If creation fails, you land back on the composer with your text still in it.

Threads name themselves. Shortly after your first message the platform writes a short title for the session, and that is what the sidebar shows from then on; until it lands (or if it never does — titling is best-effort and silent about failure) the row falls back to a truncation of the first message. Titles are generated once, for new threads, and are not rewritten as a conversation moves on.

The composer

Typing accented or CJK characters goes through your input method's own composing state, and Enter there commits the composing candidate instead of submitting — a second Enter sends. See Keyboard and accessibility for the full shortcut inventory across the platform.

The run timeline

A run renders as an ordered timeline of everything that happened, in the order it happened. The Agent's prose appears where it was said, and each contiguous stretch of interior work — thinking and tool calls — collects into one collapsible box beside a rail. Every thinking pass is kept, not just the last one, so a run that thinks, calls a tool, then thinks again shows both passes in place. A tool call on the rail shows its own status as it happens — running, succeeded, failed, rejected, or awaiting your approval.

Tool calls read as English, not as wire names. linear__create_issue renders as Linear · Create issue, with the connection's own description of the tool underneath it where the server published one, and a short summary of the result in place of serialized JSON — the raw output stays reachable, just never by default. None of that costs a network call: the names and descriptions come from what the connection reported the last time it was probed. A tool from a connection that has since been detached still humanizes; it just loses the connection name.

A work box's header tells you what it's doing: Working while it's live, with a running M:SS counter; Waiting on you while it's parked on an approval, with no counter; and Worked for Ns · M steps once it settles, counting every rail item, not just tool calls. A box defaults open only if the run was still active when the page loaded — a completed run replayed from history opens collapsed. It auto-folds once the Agent starts speaking or the run stops being live, unless you toggled it yourself, in which case your toggle wins for that box for the rest of its life. While it's actively streaming, a box's body is height-capped with its own internal scroll so a long reasoning pass doesn't push the composer down the page; the cap lifts once the run settles.

Stopping a run

While a run holds the session, the composer's send button becomes Stop, rendered in neutral ink, never red — cancellation is a decision, not a failure. The run lands as canceled rather than failed, and the conversation stays exactly where it is.

Cancellation is cooperative — it takes effect at the next durable step boundary, so a tool call already in flight finishes rather than being torn in half.

Queueing while it works

A session runs one execution at a time, so a message sent mid-run would otherwise be refused. Instead the composer stays live and Enter queues: messages you type while a run is working stack up in a "Queued" strip between the transcript and the composer, each one removable individually. The moment the session frees, everything queued merges into a single message — joined by blank lines — and sends as one turn: one send, one run, one reply.

Leaving a thread with a non-empty queue — switching sessions, starting a new chat, navigating away — asks for confirmation first, since anything still queued has not been sent. Closing or reloading the browser tab is the one exception: that drops a queue with no prompt.

When it needs you

A run can pause and wait for a person. Three things park a run:

• Tool approvals — an amber card names the tool, previews its arguments, and offers approve/deny-style buttons styled by what each option does.
• Questions — the Agent asks you something directly, with no tool chip, and a free-text reply box when the question allows one.
• Session limits — a long-running session that crosses its input-token budget stops and asks whether to continue. This prompt is approve-only in the UI, since stopping the run outright is already always available from the composer's Stop control.

Each renders inline in the thread with its own controls. A waiting run still holds the session, so anything you type meanwhile is queued.

When something goes wrong

A failed run shows up in the timeline like any other — its work boxes and prose stay exactly as they streamed, with the failure itself surfaced in place rather than erasing what already happened. The session survives a failed run; sending another message starts a new run against the same session.

The composer itself can go disabled with an explanatory hint instead of accepting input — for example while the session is busy with another run, or if the Agent behind the thread isn't published. See Troubleshooting for what each of those states means and how to recover.

The thread header

The header answers "how much room is left?", not "which build is this?". A small context meter shows the share of the model's context window the session has used — a hairline bar, the percentage, and the window size, with the exact token counts on hover — turning amber past 80%, where a compaction is worth considering, and red past 95%. It reads from what the runs actually reported, so it survives a reload; when either the usage or the model's window size is unknown the meter is simply absent rather than guessing at a number. Beside it, the model appears as its friendly preset label (Powerful, Balanced, Quick) rather than a raw provider slug.

Origin and editing

A session started by something other than chat — a Workflow's agent step, dispatched by a webhook, a Slack event, a schedule, or a form — shows a chip naming that origin, plus a second chip naming the Workflow, in both the session list and the open thread. Runs in that kind of thread show a Triggered · {message} line in place of an outbound chat bubble, and the same transcript is embedded in the Workflow's own run timeline. An Edit agent ↗ link in the thread header jumps straight to the agent editor for the Agent behind the session.

Context controls

The thread's "Session actions" menu carries three ways to manage what the Agent remembers:

• Clear context — the Agent forgets the messages so far; the thread stays.
• Compact context — earlier messages are summarized to free up room.
• Reset session — retires this session and starts a fresh one. This is destructive and asks for confirmation: a retired session can never accept another message.

Clear and compact both fire immediately with no confirmation, and leave a marker in the thread where they happened, so the transcript never silently disagrees with what the Agent knows. Those markers are part of the run's recorded history, not a passing bit of UI state, so they are still there after a reload. One honest exception: compacting a context that is already empty (or that you just cleared) does no work and therefore leaves no marker. If a run is in flight, every row in this menu is disabled.

See Sessions & runs for how a session and its runs relate, Agents for what gets published into a thread in the first place, and Durability for what keeps a run's history intact across a worker failure.