Runs

A run is the record of a flow being driven from its first step to its last: every step’s reply, every tool call, every cost, and one line at the top that says what happened. It is the unit of the debug loop and the thing a person reads when they were not there.

The record

Each run holds its steps in group order. A step carries:

field	what it is
`status`	`pending`, `running`, `awaiting-approval`, `completed`, `failed`, `skipped`
`result`	everything the agent wrote, every turn joined
`conclusion`	the final turn alone — what it concluded
`data`	the parsed value, for a step with `output: json`
`events`	tool calls, script runs with their timing, verify verdicts, refusals
`costUsd`, `tokens`, `computeSecs`, `startupSecs`	what it cost and how long the sandbox lived
`item`	for a fan-out instance, which item this one handled

The run’s summary is the first meaningful line of the last step’s conclusion — heading marks and bullets stripped. It is the row in the runs list, the subject of the notification, and what a later run sees through recall_runs(). Nothing declares it; the runtime asks every agent to open its reply with one sentence saying what it concluded, and reads the line it wrote. An agent that opens with “I’ll start by…” makes all three useless.

The run page

The step list on the left, the trace on the right, and a timeline above it — one bar per step with its tool calls marked in milliseconds, so a slow run says which step was slow. Every step shows its instruction, what it was handed from earlier groups, what it returned, its cost, and how many times it reached for a path it was not allowed and was refused (see Security).

Each agent also has an Activity page: every step it has ever run, across flows and direct runs, with that step’s own headline. It is where “how has this agent been going” is answered without opening runs one at a time.

Gates

A step marked 2! or carrying approve: true / ask: <question> parks the run until a person decides. Three doors open it, and the trace says which:

the dashboard — Approve or Reject on the run page, with a note that is kept on the record;
the emailed link — the notification carries approve and reject links when the install has a public URL;
an external event — a wait: event step is released by a POST to the run’s event URL, and what was posted reaches the next step.

The answer typed at an ask: gate reaches the next step’s prompt, so “GO, but skip the third one” is an instruction the publisher reads.

Stopping, re-running, promoting

Stop ends the run and destroys its sandbox, not just the record. A stopped run is recorded as stopped; it never quietly completes.

Re-run from a group (from: N) starts a new run at group N with the earlier groups recorded as skipped, not invented — the step reads what earlier steps wrote to storage/ and state/, which is the durable handoff. Use it to redo the interesting half after a fix.

Promote turns a run that worked into an eval case: its task and the result it should reproduce. The eval runs on every push from then on.

Handoffs

A step is handed the replies of every earlier group, oldest first, capped at about 30,000 characters with the newest kept. For a list that a later step must get exactly, or a report a person should also read, have the step write it to storage/ — a tool that takes an out= path and tees its own output is the reliable way, because a model asked to copy a long report by hand shortens it.

What a run costs, and what stops it

Every step records what it cost. A flow’s budget: is checked between groups: the group that crosses it is the last that runs, and the run fails saying so. The workspace’s and the account’s monthly budget: sit above that. See Budgets and billing.

Finished runs older than the install’s retention are pruned. Their headline survives in the eval history and in what agents can recall.