Reading an execution trace
Every decision in order, including the ones where nothing ran.
A trace is the answer to "why did it do that". Steps are written as they happen, so a run that crashed still shows how far it got.
execution trace
completed-
1
Deciding what to do 840ms
Read the question and the tools this agent holds.
-
2
Tool selected
list_ordersChose the orders listing, filtered to today.
-
3
Tool executed
list_orders120msReturned 41 rows. A read, so no approval was needed.
-
4
Response generated 1,310ms
Answered from those rows and nothing else.
- Tool calls
- 1
- Tokens
- 3,480
- Duration
- 2,270ms
Most runs look like this. The trace is written whether or not anything went wrong, which is what makes it worth reading when something does.
The step types
- •Planning — the model took a turn and decided what to do next.
- •Tool proposed — it asked for a specific call. This records the raw arguments, before validation, so you can see what it wanted rather than what we allowed.
- •Validation failed — the tool does not exist, this agent does not have it, or the arguments did not match the schema.
- •Policy denied — the call was understood and refused.
- •Approval required — it stopped for a human.
- •Tool executed / failed — it ran, with timing.
- •Response generated — it answered.
Why refused calls are shown
A trace that only showed successful calls would hide the most interesting thing about a run: the moment something was stopped. The difference between what was proposed and what was allowed is usually the answer you are looking for.
execution trace
refusedthe model proposed
delete_customer(customer_reference: 1)
-
1
Tool selected
delete_customerThe model asked for this tool with these arguments.
-
2
Policy check
Tool exists, is owned by this workspace, and the arguments match its schema.
-
3
Refused by policy
The person who asked holds the viewer role, which does not carry tool.execute.
Refused before the connector was reached, and recorded as a refusal rather than quietly dropped.