Reference

Runs

A run is one execution of an agent — every step it reasoned through, every tool it called, every action it proposed, with its outcome, token usage and cost. The run history and the run detail page are your forensic record of what each agent actually did.

What this area is for

The Runs list shows every agent execution in your organisation, live and historical. Each run is pinned to the immutable agent version that produced it, so a run always reflects the exact configuration in force at the time. Re-running or republishing later never rewrites the record.

Open any run to see its step timeline: the replayable narrative of everything the agent did, from model calls and tool calls through to proposed actions and approval waits. Alongside it sits a usage panel with token counts and cost, the run's input, and, once it finishes, the result.

The run history

The list opens newest-first and is fully filterable; every filter and the active column sort live in the URL, so a filtered view is shareable and survives a refresh. You can narrow by:

• Agent: runs from a single agent.
• Status: queued, running, awaiting approval, completed, failed or cancelled.
• Trigger: how the run started (for example manual or scheduled).
• Mode: live only, sandbox only, or both.
• Initiator: who started it. Runs with no initiator are shown as Scheduled.
• From / To: a date range.

You can sort by Started and Status; each row shows the agent, status with any outcome flag, trigger, who started it, total tokens, cost and when it began. A completed run whose proposed action later failed still reads completed, so the list surfaces a failed-action count to flag it. The list updates in real time as runs progress.

Inside a run

The detail page is built around the step timeline. Each step is one thing the agent did: a model call, a tool call, a proposed action, a simulated action, an approval wait, a retrieval, or a summary. A step expands to reveal its input and output payloads (loaded just after the page paints), its duration and token use, and any error. While a run is in flight the page streams the agent's reasoning live and refreshes as each step lands.

The side panel carries the run's Usage (input tokens, output tokens and cost), the model and provider used, the original Input, and, on completion, the Result summary. If the agent's version opted into retrieval, a Retrieved knowledge panel cites the source documents (name, id and similarity score) that grounded the run.

Actions, approvals and audit

Side-effecting tool calls become action cards on the run. Each waits for the Approval Centre unless the agent's sign-off or earned autonomy lets it go ahead on its own; high-risk changes always wait. A card shows the tool, its risk level, the (redacted) payload and the approval outcome inline — who approved or rejected it, when, and any decision note. Decisions are never made from the run page: when an action is awaiting approval, the card links you through to the Approval Centre to decide it there.

When a run is paused on awaiting approval, a banner tells you how many decisions are pending and links straight to them. Every run and its steps are projected to the append-only audit log, so the record is permanent.

Cancel and re-run

Two actions are available from a run's header band, each behind its own permission:

• Cancel run (requires runs.cancel) is available while a run is still active (queued, running or awaiting approval). The run halts at its next safe checkpoint; tokens already consumed are still metered and the step record is retained. You are asked to confirm first.
• Re-run with same input (requires runs.execute) is available once a run has finished. This starts a fresh manual run of the same agent with this run's input verbatim; it never mutates the original. The new run must pass every dispatch guard (your plan limits, an active agent, a published version), so it can be declined with a validation message.

Dry-run vs live

A sandbox dry-run lets an agent reason for real while every change, and every call to a connected app, MCP server or custom tool, is simulated — nothing is sent, created or changed, and no approval is requested. Built-in document and web tools (search and page fetches) still run for real. A dry run doesn't use your monthly run allowance or appear on your bill, but your plan includes a set number of dry runs each day, and evaluation cases have a daily allowance of their own. Dry runs and evaluations also share a daily usage limit on each plan. Once it is used up, new ones can’t start until midnight (UTC), and an evaluation that was already running stops part-way; the cases it didn’t reach show as not run, and the publish check keeps their earlier results. An evaluation suite can hold up to half the evaluation allowance, so on most models you can run it on a draft and on the published version the same day; on dearer models today’s usage limit may cover only one, and a large suite may need to be made smaller before it can run at all. If you move to a smaller plan, remove cases from a larger suite before running it. Sandbox runs are badged in the list and carry a banner on their detail page.

Instead of executable action cards, a sandbox run shows would-be actions: exactly what the agent would have done live, including the redacted payload it would have used, surfaced as a forecast. Because they produce no real outcome, sandbox runs are never rated and never reach the approval gate. Use the Mode filter to separate live and sandbox history.

Next steps