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. The newest workflow run is the card at the top of Runs, as a Task that runs a Workflow describes, and older workflow runs keep their steps in the list.

Runs and Browser use 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.

Agent leads also leave Runs that belong to no Task: a Team lead's heartbeats, named Triage, and the reviews of a Goal or Project lead. They appear on the Runs tab of that Team, Goal or Project, newest first and 25 at a time, and open in the same Run window as a Task's Runs. A failed check-in keeps its Retry in Inbox.

Retry a failed attempt

Recover failed Task execution with Run again in its Inbox item or the Task's current-step controls. It requests the current step through the normal approval, dependency, budget, and execution checks. Historical Runs keep their evidence without a Retry control that could replay old instructions. The generic Inbox failure item stays out of Activity so it does not duplicate the native recovery card.

Independent discussions, reviews, backlog checks, and Chat keep their source-specific Retry action when that source can still be retried. Retrying creates a fresh attempt for that conversation or review and leaves the failed Run unchanged. It never switches to the Task's execution step.

An accepted current-step request clears matching failure notices that existed when you requested it. Independent conversations, reviews, later failures, and decisions you already made remain intact.

After processing newer successful work at the same step, Task Machine clears the older failed-run notice from active Inbox attention. Success in another phase, review, or conversation does not clear that notice. The failed run and its resolved Inbox item remain in history.

A run's execution status remains separate from Task Machine processing its result. If that processing stops after repeated failures, the Inbox offers processing recovery without starting another agent run.

Once you retry processing or dismiss the alert, it leaves Activity. The run and Inbox record stay available.

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 events load automatically. Scroll up for earlier events. Very long transcripts keep a bounded window, so scrolling back down loads the later events again. 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.

If Task Machine cannot confirm saving some transcript events, the transcript shows a warning with their count. The warning means the history may be incomplete, not that the work failed. It does not restart completed work or change the Run's result.

Comments and reactions received during a Run appear as right-side messages with the sender's name. Conversational Runs receive steering only for their own Agent and comment thread, while separate threads keep their own Runs. A comment on a Task also reaches the Run executing that Task when it is addressed to the executing Agent, even before that Run has started, so you can redirect work in progress without waiting for it to finish and without a second Run answering the same comment. You can read or copy the instructions the agent received, and Task Machine's own messages have a separate label.

Task Machine supplies its operating rules through the model's system instructions. Your request, recorded decisions, memory and conversation history remain separate context. The record retains the original compiled instructions and the effective system instructions delivered by the Worker.

A Run that received comments, reactions or Task Machine interventions shows a Steering tab beside Transcript in the Run modal. The tab appears when the first one arrives, and a Run without any shows only its transcript. Steering is a timeline of those events, newest first. Scroll down to load older events.

Each entry is a card showing who sent it and when. A comment shows the sender's avatar and the comment with its formatting, mentions and links. A reaction shows who reacted and with which emoji. A warning, time update or stop request from Task Machine shows one short sentence.

A mention of a record you cannot read shows its plain name instead of a link.

Each event shows whether its message is queued, delivered or was not delivered. Task Machine marks comments and reactions handled after accepting the agent's report. A comment also requires that agent's reaction.

If the same agent handles a queued task comment in a later conversation, the original message can also show handled. Its delivery label still records whether the original attempt delivered it.

Handled records acknowledgment and does not confirm that the agent followed your direction. The Transcript tab keeps the full delivered messages.

On current Workers, Task Machine watches for repeated tool calls and failures without observable progress. It first asks the agent to change its approach. If the same loop continues after the agent receives that message and has time to respond, Task Machine asks it to stop and submit a report. Steering keeps both the warning and stop request visible, separately from the agent's submitted Run report. Required checks and review still apply, and the reviewer decides when the Task is done.

On current Workers, Task Machine also checks progress every five minutes during a running Task, using the Task's requirements and recent tool activity. Research and reading can count as progress without file changes. Signs of being stuck or drifting from the requested outcome produce a warning in Steering and the transcript. This check cannot stop the Run or decide that the Task is done. If it is unavailable, the repeated-call rules still apply. These checks use a small amount of workspace usage, including for local agents.

Finishing reminders, over-budget reminders, a time check for every 15 minutes of work on the Task and changes to the time budget also appear in Steering and the transcript. These use cumulative implementation, review or rework time against the plan estimate, or the Task's time budget work limit when that is smaller, without counting waiting. Planning, Discussion and Recheck have no allowance or time reminder. A reminder asks the agent to focus on essential work and keep working in the same run while required checks and review stay in place.

Report-time warnings also flag a bucket or total work reaching 150% of its estimate. A new run or a fresh remaining-time report does not reset the comparison. These warnings never stop a run or mark the task done. See Duration and usage.

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 recorded usage across its runs and separates spend by execution stage. Rework shows correction work. Discussion shows comment and reaction turns, and Recheck shows checks of blocked work or pull-request updates. Historical runs keep their originally recorded labels.

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.

Substantive Task-execution Runs update the Task's rolling summary, shown in the Task's Summary tab: 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 plan and history.

An authorized summary update is part of the report the Agent submits at the end of its Run. Unchanged reports preserve the existing summary. A summary is up to 15 bullet points within 4,000 characters, each a complete point in plain sentences. Links, bold, italic, and inline code are allowed, but not paragraphs, headings, or other block formatting.

A report that waits for Events keeps its original event condition and scheduled check time in history. The current Next step card shows whether the Task is still waiting, received a matching event or is held by another check. Event receipt alone does not mean a Run started. The next Run receives the complete event as an input file when that event released the step, and still inspects the current source before acting. A scheduled check or Run next without a matching event supplies no event file.

Comment and reaction Runs report on their own conversation. They can answer a question or perform authorized actions, but their report cannot replace the Task's summary, estimate or main next step. Automatic follow-ups remain with that Agent and thread.

An obsolete pull-request review keeps its evidence in Run history without replacing the current Task summary. Ending that review does not reject the replacement revision or stop the Task's current work.

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 Cloud execution or a Local Worker provides execution. Work may wait for timing, capacity, access, an approval, or a failed attempt.

Each execution is temporary. The Agent finishes its own commands, such as builds and tests, and collects their results before its final report ends the execution. A later Run cannot rely on those processes or temporary files surviving. Independently durable outside work, such as GitHub checks, can keep running between scheduled inspections.

A Queued run can be held by another run for the same agent that needs Connector sign-in or credential approval, even on a different task. Activity, Runs, and the run modal explain that access blocker. The explanation updates when the blocker resolves.

If you can manage the Connector and its credentials, Log in again opens your recovery item in Inbox. When no active recovery item is available, Open Connectors takes you to your installed Connectors. Viewers without that authority see the reason without recovery controls.

A Run waiting for credential or Connector access resumes automatically when that access is restored. Instruction updates prepare that same Run for resumption without creating a fresh attempt or removing its earlier actions and evidence. Failed Task execution uses the current-step controls, while independent work keeps its own Retry action. A deliberate stop does not automatically restart work.

Resumption may use a new runtime. Saved conversation history does not mean that browser sessions, processes, ports or files survived.

On current Workers, the agent can restore verified conversation history, check current state and continue in the same Run when a browser or process is lost. An action tied to the lost browser or process stays blocked, and changed actions still pass through the usual approval checks. If the conversation cannot be restored, the Run fails rather than starting an empty conversation.

An approval remains limited to its exact operation and target. An interrupted command may already have had effects. Inspect the destination before retrying an uncertain write.

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