Observability
Interpreting execution traces in the Trace Viewer
A completed cycle carries its whole history: each station's output in order, timestamped, with the tool calls a station made and the cost each one booked. Reading a trace is reading that list from the top.
Open Cycle history in the consoleWhat a trace holds
A run records a step per station in order, each timestamped, each carrying what that station produced. Where a station made tool calls, those are steps too — with the action called and the outcome the gateway recorded.
Reading one
Read from the top. The first step whose output stops matching what the next station needed is usually where the problem is — not the station that eventually failed.
Cost, per step
Each step records what it cost, so a run's total is the sum of its parts rather than a figure arriving from somewhere else. That is what makes an expensive run diagnosable: you can see which station, and which call inside it, did the spending.
What a bounded loop looks like in a trace
A station's tool loop stops after a small number of steps, and each observation is truncated before the model sees it. A trace that ends sooner than you expected, or an observation that stops mid-sentence, is usually that bound rather than a failure.
- Steps
- 6 per stationThen the loop stops
- Observation
- 4,000 charsTruncated for the model
- No grant
- No tool stepsPlan-only run
Put it into practice
Run a fleet with these guardrails on from day one.
Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.