Monitor runs

The run monitor is the operational record for agent, pipeline, and team execution.

Read the status

Open Runs and filter by status. Beyond the finished states — Completed, Failed, and Cancelled — the filter distinguishes work that is moving from work that has stopped and is waiting:

Pending and Running — execution is under way. Running means work is in progress; it does not guarantee useful output yet.
Awaiting reply, Awaiting approval, and Awaiting plan approval — the run stopped and needs a person. It will wait indefinitely until someone responds.
Paused and Paused for replan — execution is suspended and can be picked back up.

Paused and awaiting runs are counted in the badge on Runs in the sidebar, so you do not have to watch the filter to notice them. A run in one of these states is waiting without consuming resources.

Attribute runs to projects and cost centers

In a shared workspace, Runs also filters by Project, Ticket, and Cost center. These are free-text tags recorded on the run when it starts. There is no list to pick from, so a workspace only gets a useful breakdown if people spell them the same way — agree on the values before you rely on the filters.

Where a tag is set depends on how the run started:

Team and pipeline runs — fill in Project, Ticket, and Cost center on the run launcher before starting the run.
Schedules and inbound webhooks — set the tags on the trigger itself, when you create or edit it. Every fire copies them onto the run it starts, so a recurring job is tagged once rather than once per occurrence.
API calls — send project_tag, ticket_tag, and cost_center_tag in the request body of Run an agent, Start a workforce run, or Run a pipeline.

Runs started from a chat carry no tags. Child runs inherit their parent's, so tagging the top of a fan-out tags everything beneath it.

Tags are fixed once a run starts — there is no way to re-tag finished work, so a misspelling stays in the record. They also affect nothing operational: no budget, limit, or approval reads them. Admins and owners can download the breakdown from Analytics under Spend attribution, which groups spend by the same three tags.

Read the verification result

Execution status and verification status answer separate questions:

Completed · Checks passed — execution finished and every required result check passed.
Completed · Not checked — execution finished, but no configured result check confirmed the output.
Failed, with Checks failed under Result checks — execution reached a result, but at least one required check rejected it. Team runs may pause for replanning instead.

Output-schema checks run only when execution has produced an otherwise successful terminal answer. A mismatch fails the run and records verification_failed. Pauses, cancellations, provider outages, tool failures, and other operational failures stop before output verification, so they remain not_evaluated rather than becoming schema failures.

Runs configured with Require the run to create a file have a separate required File created check. In the API, the setting is require_artifact=true and the check is named artifact_requirement. Creating at least one downloadable file passes it; finishing without a file fails the run and records verification_failed. When a run also has an output schema, both checks must pass. Creating a file when it is not required, or providing files from earlier runs, does not add this check.

Open a run's Result checks section to see which checks ran, whether each check was required or advisory, and when it ran. For output-schema checks, the platform validates one exact JSON object locally against the original Draft 2020-12 contract. Provider-native structured generation does not count as verification by itself.

Failed schema checks show property paths and constraint names without exposing the rejected values. A passing schema check proves structure only. It does not establish factual accuracy, sound reasoning, or task quality.

The File created check lists the files that satisfied the requirement when the run finished. Deleting a file later does not change that historical result.

Aggregate views keep the two signals separate:

Completion rate is completed runs divided by completed plus failed runs. Cancelled runs are excluded.
Results passing checks is runs whose required checks passed divided by completed runs. Completed runs with no applicable checks reduce this rate.

Inspect the execution tree

Open a run to see its events and nested calls. The call tree shows which agent or team invoked each child, how long it took, and where resources were consumed.

For pipeline runs, inspect individual step input, output, retries, and failure handling.

Under Files created, preview a supported file to inspect it without first downloading it. Choose Add to Knowledge when a trustworthy run file should become reusable source material. Choose who can access the copy and where it belongs. The Knowledge copy remains available independently of the run file and links back to this run.

Images made with Generate an Image appear here too. See generate and edit images for downloading them, making further edits, and reusing them in another run.

Diagnose failures

Start with the first meaningful error, not the final cascade. Check:

whether the selected model and tools were available;
whether input matched the expected shape;
whether the final JSON matched every required output-schema constraint;
whether required knowledge or credentials existed;
whether policy, budget, or execution limits blocked the action;
whether a downstream service failed temporarily.

Control active work

Which controls a run offers depends on why it stopped. Open the run to act on it.

Cancel — available while a run is active or paused. Use it for work that is no longer useful or is consuming resources unexpectedly. Cancellation can finish asynchronously, so the visible state may take a moment to settle.
Resume — available on Paused and Paused for replan runs, and on runs paused by a recovery issue or an exceeded limit. Resuming continues without repeating completed work. Fix whatever caused the pause first: a resumed run that hits the same limit pauses again.
Approve Plan, Deny Plan, or Change Plan — offered on Awaiting plan approval runs.

For Awaiting reply and Awaiting approval, open the run to answer the pending question or approve or deny the requested tool action. You can also respond from the associated chat. These requests must be answered by the person who started the run; an admin's permission to cancel a run does not let them answer on someone else's behalf. A generic Resume cannot supply the missing answer or approval.

If the response is recorded but the run cannot restart, follow the recovery message and refresh the run. Do not submit the same decision again.

Use Activity Log when you need to identify the user or machine principal responsible for an action.

Clear runs

On Runs, open Clear Runs and choose a status group. Clear Paused Runs includes runs awaiting input, approval, or a plan decision. Clear All Runs includes every finished and paused run and requires you to type the confirmation phrase shown in the dialog.

Clearing applies across the current workspace to matching runs that existed when clearing began. The list's page, agent, and tag filters do not narrow it. Members can clear only runs they started. Running and pending runs are excluded, and a run tree can be skipped if a child is still active or a file is still in use.

Confirming permanently deletes eligible runs together with their nested child runs and files. Copy any output you want to keep into Knowledge first; that independent copy survives removal of the original. Deletion cannot be undone.

The dialog reports progress as batches finish. Stop After Batch finishes the current batch and prevents another from starting. Leaving the page also stops after the current batch; neither action restores runs already deleted.

Skipped runs remain listed. If clearing fails, some deletions may already have completed. Retry from the dialog to continue clearing the remaining runs, and address any reported blocker before starting another sweep for skipped runs.