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 sitting in one of these states is not stuck; it is holding a durable checkpoint and consuming nothing while it waits.

Read the verification result

Execution status and verification status answer separate questions:

• Verified — the platform ran at least one required check and every required check passed.
• Completed — Unverified — execution finished, but no verifier established that the result met a checked contract.
• Verification Failed — at least one required platform check failed.

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.

Open a run's completion evidence 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.

Evidence records SHA-256 fingerprints of the schema and checked output. Failed checks show safe property paths and constraint names for at most 20 validation errors; rejected output values are not stored in evidence. A passing schema check proves structure only. It does not establish factual accuracy, sound reasoning, or task quality.

Aggregate views keep the two signals separate:

• Completion rate is completed runs divided by completed plus failed runs. Cancelled runs are excluded.
• Verified rate is verified runs divided by completed runs. Completed but unverified runs 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.

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. Some durable executions finish cancellation 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 checkpoint failure or an exceeded limit. Resuming continues from the checkpoint rather than 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.

Runs in Awaiting reply and Awaiting approval deliberately have no Resume button. They continue when someone answers the question or responds to the tool-approval request in the chat, because resuming past an unanswered prompt would skip the very thing the run stopped for. Open the chat rather than the run to clear these.

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