ConceptsSessions & runs

Sessions & runs

A session is a conversation with a published Agent; a run is a single execution. Runs come in two shapes. An agent run is one turn inside a session — what chat produces, and what a Workflow's agent step produces as a child. A pipeline run is one firing of a Workflow: it has no session of its own — its record is a per-step timeline instead of a transcript.

Both stream their progress to the browser live over resumable SSE — reconnecting with a Last-Event-ID replays missed events rather than restarting — so a dropped connection never loses run history.

What a run contains

An agent run is the ordered stream itself: everything the Agent said, everything it thought through, every tool it called, and every point where it stopped and waited. It belongs to exactly one session and runs against exactly one agent version — the version its session pinned when it began, never a later one. How that stream renders is covered in Chat.

A pipeline run is the ledger of its steps: one entry per step instance — a loop body yields one per iteration — with each step's status, attempts, timing, and rendered input and output. When a pipeline reaches an agent step, it dispatches a child run: a real agent run with a session of its own — fresh by default, or a continued Slack-thread session — linked from the parent step; in the run's timeline view, the child's whole transcript is embedded in place.

One run per session

A session runs one execution at a time. While a run is active the session is busy, and a waiting run (parked on a human approval) counts as busy too — new run requests against a busy session are refused rather than interleaved. In chat that rule is invisible: messages you send during a run are queued and delivered when the session frees.

Pipeline runs have no session, so a different rule bounds them: by default a Workflow runs one pipeline at a time, and a trigger firing mid-run is skipped rather than overlapped — see Workflows.

Waiting

Three things park an agent run on a person before it can continue:

  • Tool approval — a gated tool call needs a yes before it runs.
  • A direct question — the Agent is asking you something and needs an answer to proceed.
  • A session limit — the session has crossed its input-token budget, and continuing needs your say-so.

A waiting run still holds the session exactly like an actively streaming one does. And waiting propagates: a child run that parks on an approval parks its parent pipeline step — and the whole pipeline run — until the child's prompt is answered, right there in the run timeline where the transcript is embedded.

How a run ends

A run finishes in one of three states: succeeds, fails, or is canceled — the state a run lands in when you stop it. Cancellation is a decision rather than an error: a stopped run is never reported as a failure, and canceling a pipeline run also cancels any child run it has in flight. A Workflow's declared Slack reply is only ever sent from a run that succeeded — deliberately, because a reply from a run nobody let finish isn't one the platform should send on your behalf.

A failed run doesn't take a session down with it. The session is still there and still usable afterward — sending another message starts a new run against the same session, same pinned agent version. A failed pipeline run likewise leaves its Workflow ready for the next trigger; its timeline shows exactly which step failed and why.

Sessions end, too

Resetting a session retires it permanently — a retired session can never accept another message. Long sessions also age out on their own; when that happens, the next message starts a fresh session against the Agent's current published version.

Where runs are visible

Chat keeps a conversational session's runs open live in the thread. A Workflow's runs live in its Runs tab, each replayed as a step timeline — and the agent-step child runs are visible right there, embedded in their step's drawer, transcript and approvals included. See Durability for what keeps that history intact across a worker failure, and Troubleshooting if a run's state doesn't match what you expected.