Skip to content

The agent you can't debug

When a user says the agent did the wrong thing and the original run wasn't traced, you're left re-running and guessing, because there's no record of the prompts, tool calls, and results that produced the behavior.

incident

A user reports a bad answer, the run wasn't recorded, and the team spends an afternoon trying to reproduce something they can't see.

where_are_you

The maturity ladder, worst to best

These are the rungs the Agent Reliability Scorecard scores for this dimension, straight from the tool. Find where your agent sits, then aim for the top rung.

  1. We re-run it and guess; the original run isn't recorded

  2. We have logs of the final output, but not the steps

  3. Each step (prompt, tool call, result) is traced and inspectable

  4. Full step traces, and eval suites that would have caught ittarget

  5. We try a couple of cases by hand

  6. A short manual checklist before release

  7. A saved eval set we run before each release

  8. Automated evals and output guardrails gate every change in CItarget

the_fixMake every run replayable and testedTrace each step (prompt, tool call, result) so you can see why the agent acted, and gate prompt/model/tool changes behind an eval suite so a change can't silently regress behavior.

why_it_matters

An agent's behavior is emergent: it comes out of a chain of prompts, tool calls, and results that you don't control step by step. When something goes wrong, the only way to understand it is to see that chain. If all you kept was the final output, you're reduced to re-running the task and hoping it misbehaves the same way, which for a non-deterministic system it often won't. The run that mattered is gone.

Make every run replayable and every change tested. Trace each step, the prompt, the tool call, the result, so you can see why the agent acted, not just what it returned. Then gate prompt, model, and tool changes behind an eval suite, so a change can't silently regress behavior that used to work. Observability and evals are what turn "the agent feels flaky" into a specific step you can fix and a test that keeps it fixed.

final output onlyre-run and guesstrace every step; gate changes behind evals

faq

Questions & answers

How do you debug an AI agent that did the wrong thing?
You need the trace of the run: the prompt, tool call, and result at each step. With only the final output you're stuck re-running a non-deterministic system and guessing. Trace every step so you can see why the agent acted, and keep an eval suite so you can reproduce and lock the fix.
What should you log for an AI agent?
Each step of the loop: the prompt sent, the tool called with its arguments, and the result returned, tied to a run id. That's what lets you replay a bad run instead of re-running and hoping. Pair the traces with an eval set that gates prompt, model, and tool changes so regressions are caught before release.

Fixing one failure mode is a day. Hardening the whole loop is the work.

I review where your agent loop terminates, how it escalates, how it fences tool output, idempotency on the side effects, and the evals that catch a regression before users do. Book a call, or leave your email.

Book a call

No spam. You'll get a reply from me.

Prefer proof first? See how this plays out in real case studies →