Run history

A Run records one execution attempt. Open it when you need the model, timing, transcript, or failure evidence behind work on a Task or in Chat. Task completion remains a separate decision.

Runs keeps complete execution evidence

Runs is the complete execution record. Every agent and workflow run remains there, including successful work, cancellations, failures that later recovered, and blocked-task rechecks. Each workflow run shows the ordered steps from the exact workflow version it used, with each step's type and latest available status.

Runs, Browser use, and Workflow appear only after the task has that kind of history, keeping a new task focused on Activity. Activity reads from oldest to newest, while Runs starts with the newest work and loads older pages automatically as you scroll down. Runs appends 25 records at a time.

New comment threads join the end of the Activity papertrail, while replies update their original thread without moving it. Long-lived tasks remain complete without loading their whole history at once.

Retry a failed attempt

When a failed or timed-out agent run can safely continue from its current task state, Retry appears on its Runs card, in its run detail, and on the matching failure item in Inbox. The Inbox item stays out of Activity so it does not duplicate the canonical newest failure card.

Retrying creates a fresh attempt and leaves the failed run unchanged in the history. The action disappears as soon as another attempt exists or the task state no longer allows that recovery.

Inspect a Run or read the current summary

Open an execution Run to inspect:

• The concrete model and whether Auto or a fixed choice selected it.
• The Worker and timing.
• Recorded tokens and customer usage.
• The transcript of tool calls, reasoning, supplied instructions, and errors.

The newest transcript page loads automatically, and you can move to earlier or later events without loading the complete transcript at once. Search, page fetching, and browser rows name one or two public domains and otherwise count the sites involved, so the collapsed history stays informative without exposing full URLs.

Workflow Runs and Chat use the same transcript presentation. You can read execution evidence in the same way across those surfaces.

The task's sidebar adds every run into one total and separates spend by planning, implementation, review, verification, rework, and follow-up, so recurring checks and pull-request updates no longer inflate Verification.

When a conversation in Chat produces executable work, create a Task to give that work its own assignments, status, and execution history. The original Chat retains its conversation history and independent Runs. Questions and approvals raised on the Task keep their context there and route the decision to the Inbox.

Every substantive agent Run rewrites the Task's rolling summary, one concise account of the current outcome, evidence, corrections, useful failed approaches, blockers, and next action. The Run starts from the existing summary and replaces stale detail instead of appending a transcript or copying the Work Spec and history.

A summary stays within 4,000 characters and 15 simple bullet points. It may use plain paragraphs, links, bold, italic, and inline code, but not headings or other block formatting. The update is required: if a successful Run skips it, Task Machine starts one summary-only repair.

Infrastructure failures are excluded because they are Task Machine errors, not lessons for the agent.

Execution lifecycle

A Task can need planning, implementation, review, and follow-up Runs. The Agent is the responsible member, while the Worker and Runtime provide execution. Work may wait for timing, capacity, access, an approval, or a failed attempt.

Use Task specs for planning, Reviews for results, and Troubleshooting for waiting or failed work. An offline computer is only one possible cause.