When a step produces the wrong answer, takes too long, or fails outright, the record of what it actually did is kept. This article covers where that record lives and how to read it.

Anywhere a step's agent has worked — on the step itself, on a work item, in an error report, in a tool's call history — its activity appears as a single line you can click to expand. Expanding it opens the run in full, in the order it happened:

Nested runs expand too. When a step calls a custom AI tool, that tool's own agent run appears inside the parent run and can be opened the same way, so you can follow a decision down through several layers without leaving the page.

This is the single most useful diagnostic in the product. Most "why did it do that?" questions are answered by the arguments of one tool call — a search that returned nothing, a document the agent could not read, a value it filled in from the wrong property.

A finished run carries a summary line: when it started, its Total duration, the time it spent waiting on the AI model and on tools, and what it cost.

The split is the interesting part. A run that took four minutes and spent three of them in tools has a very different problem from one that spent three minutes in the model. The first is usually about which tools the step reaches for and how much data they return; the second is usually about how much you are asking the model to do in one step.

Next to the total, an information icon offers Why so long?. It walks the run, groups the work by what caused it, ranks it by duration, and explains what it found.

The breakdown is measured, not guessed: every duration and percentage is computed from the run itself. What the explanation adds is the part you cannot compute — why six calls to the same tool happened at all, what that says about how the step is written, and what to change. Typical findings are a tool called repeatedly where one call would do, a retry after a failure that cost the run twice, and a nested tool run that dominates its parent.

Time spent waiting on a person — an approval, a reply — is accounted for separately and not counted against the automation.

Open a work item and you land on its detail pane, which organises the same history around the item rather than around the agent's run. Its tabs are:

Input and Result also surface extra values: things the agent produced that no property was declared for. A value showing up there repeatedly is a hint that your data model is missing a column.

Every custom tool has a Call history tab on its detail page, under Custom-built tools. It lists that tool's past invocations, newest first, with the input each call received, the output it returned, and a status chip. Each entry expands into the full run.

This is where you go when a tool is the suspect rather than the step. Seeing twenty real calls side by side tells you quickly whether a tool is being called with the arguments you expected, whether it fails on a particular shape of input, and whether its output is stable enough for the step to rely on.

Call history is also the cheapest source of test cases you will find: any call in the list can be captured directly as a test case with Add to tests. See Testing your custom tools.

Open Monitor in the left nav and select the Errors tab. Monitor is available to thunk admins.

The tab has two halves.

The error-rate chart covers the last 30 days, in your local time zone. Each day shows how many agent runs succeeded and how many errored, with the daily error rate as a line, and a breakdown by error category. This is the view that answers "is this getting worse?" — a single failure is noise, a rising line is a problem.

The error list below it holds the most recent errors, newest first. Each record shows:

Beside the remediation note on a failed run is a What went wrong? action. The note tells you what kind of error this was and what generally helps. This reads the actual run and tells you what happened in this one — which is usually the difference between a generic retry and knowing which tool call broke and why.

For the full catalogue of errors — what each one means, why it happens, and what to do next — see Troubleshooting Errors.

The views above examine one run at a time. For thunk-wide operational views — throughput, cost, and how the workflow is performing in aggregate — see Observability and Monitoring.