Debug and Diagnostics: Seeing Why an Agent Run Went Sideways
Agents fail quietly. SE Studio's debug mode lets you replay a run step by step, and diagnostics shows where the time and tokens actually went.
Agents fail quietly. A run finishes, the diff looks plausible, and only later do you notice it spent six minutes thrashing on one tool call, or that it edited the wrong file twice before getting it right. A terminal scrollback does not help you here. You need to see the run, not re-read it.
Two questions: what broke, and what was slow
When a run disappoints, there are really two questions. The first is correctness: what did the agent actually do, in what order, and where did it go wrong. The second is performance: where did the time and the tokens go. SE Studio answers them with two modes that read from the same recorded run.
Debug mode: replay the run
Every execution already leaves a trail. Runs persist their metadata, events, and logs under .multi-code/, so debug mode does not need the agent to still be alive. It replays the recorded run as an ordered sequence: each prompt, each tool call and its result, each file edit, and the evidence published at the end.
- Step through the run in order, or jump to the step where state changed.
- Inspect the exact prompt and the tool calls the agent made.
- See which files were touched and what the diff was at each step.
- Read the evidence and review verdict the run produced.
Diagnostics: where the time and tokens went
Run diagnostics
Diagnostics turns the same run into a waterfall: how long each phase took, and within a phase, where the time and tokens went — model thinking versus tool calls versus waiting. A span that dominates the run is exactly the thing you would otherwise never notice from a successful-looking diff.
Why it matters
Once agent work is something you ship, run cost and run reliability stop being abstract. Debug mode makes a misbehaving run reproducible instead of mysterious. Diagnostics makes a slow or expensive run measurable instead of a vague feeling. Both come from the evidence the run already recorded — which is the same reason Sprint Engine and Switchboard exist: the work should leave behind enough proof to trust.
See why a run misbehaved instead of guessing from the output.