The most expensive failure in scheduled AI work is not a run that crashes. A crash announces itself. The expensive one is a run that succeeds, produces something fluent and plausible, and did almost nothing to earn it.
You cannot detect that by reading the result. Fluency is exactly the quality that makes it invisible. You detect it by reading the trace.
What a trace is
Every run records an ordered sequence of steps, each one of four kinds:
| Kind | What it records |
|---|---|
model |
A model turn, with duration and token usage. |
tool_call |
A tool the model asked for, and the arguments it sent. |
tool_result |
What came back. |
error |
A terminal failure and its category. |
Read in order, that sequence is a record of what happened rather than a summary of it. The distinction matters because the summary was written by the thing you are evaluating.
Four things to look for
1. Did it look before it concluded?
Scroll to the tool calls before you read a word of the output.
An audit with no tool_call steps is a generated opinion. It may even be a
good one — models know a lot about what security problems usually look like —
but it is not an audit of your repository, and it will be equally confident
next week when something real is wrong.
This is the single highest-value check, and it takes about four seconds.
2. Do the arguments match what you asked for?
You asked for changes since last Monday. The tool call fetched the last 30 commits. Those are different questions, and the output will not tell you which one was answered.
Argument drift is the quiet failure mode of recurring work: the instruction is ambiguous, the model resolves it differently on different weeks, and every result looks fine in isolation. The trace is where the ambiguity becomes visible.
3. How much of the budget did it use?
Read the timing between steps against the routine's idle timeout, and the
total duration against its deadline. A run whose longest quiet stretch nearly
reached the idle limit did not finish comfortably — it finished just in time,
and the week a third-party API slows down it will stop with idle_timeout.
Headroom now is the difference between a routine that runs for a year and one that starts failing in November.
4. Where did it repeat itself?
Three near-identical tool calls in a row usually mean the instruction did not say when to stop looking. The model is exploring because nothing told it what "enough" is.
That is an instruction fix, not a model fix. Bigger models explore more expensively.
A worked comparison
Two runs of the same routine. Both succeeded. Both produced a readable five-finding brief.
Run A
1 model 1.9s
2 (end)Run B
1 model 1.2s
2 tool_call github__list_commits { since: "2026-06-23" }
3 tool_result 47 commits
4 model 2.8s
5 tool_call github__get_file { path: "src/auth/session.ts" }
6 tool_result ...
7 model 4.1s
8 (end)Run A wrote about security. Run B audited a repository. Only one of them will tell you something you did not already know, and the outputs are hard to tell apart.
What the trace does not tell you
Worth being straight about the limits.
A trace shows that a tool was called and what it returned. It does not show that the model used what came back — a run can fetch the right file and then write a paragraph unrelated to it. The trace narrows where to look; it does not replace reading the result.
It also cannot tell you whether the finding matters to your business. That judgement is the part that stays yours, and it is the reason the schedule gate exists: a routine cannot be activated until one manual run has succeeded and, implicitly, someone has looked.
Build the habit early
The most useful time to read a trace is the proof run, before anything is scheduled — that is when a bad instruction costs one review instead of a quarter of unnoticed output.
After that, a reasonable cadence is: read the trace whenever the result surprises you, and once a month when it does not. The second one is where you find the routine that quietly stopped calling a tool six weeks ago.
Runs and traces covers what is recorded, what is redacted, and how usage is aggregated.