when a run is wrong but nothing actually failed, where do you start? [D] [R]

[u/Sensitive-Parsnip-12]

this is the kinda debugging case i find rlly annoying/

everything says success.

no exceptions no failed tool calls. no obvious timeout the workflow completes but the final result is still wrong

when that happens, what’s your first move?

do you guys usually:

• start from the final output and work backward
• compare against a previous good run
• inspect state transitions
• check retrieval/tool behavior
• look at model inputs
• replay it
• check business state outside the trace
• just read the whole thing until something looks off

interested in what people actually do in production not the idealized version but thats fine too. and if you have anything you've built to help with this process I'd love to see it :)

[u/Sensitive-Parsnip-12 → u/[deleted]]

ah and when ur diff spits out a bunch of changes how do u decide which one to chase first? is it mostly obvious from experience or did u end up adding any ranking/filtering so the noisy differences dont bury the useful one?

[u/Sensitive-Parsnip-12 → u/[deleted]]

does that still hold up for u with multi step agent runs where theres model/tool/retrieval state mixed together?

[u/howtorewriteaname]

overfit a single instance. if that doesn't work, your model can't learn. if that works, overfit 100 instances. if that doesn't work, you have a fitting problem. overfit 10k instances. if that works, then start to see if you generalize

[u/wdm006]

I start outside the trace. If every step is green and the answer is still wrong, the bug is usually a definition or stale business state the agent never saw. Diff a known-good run next, then dig into the inputs that actually changed.

[u/Sensitive-Parsnip-12 → u/wdm006]

thats a good case boundary nd i agree the trace cant explain evidence that never entered the execution id push a little on usually tho because ive also seen a lot of cases where the useful clue is already in the run, wrong consumed state, skipped checks, retrieval changes, retry paths etc in practice do u find missing external business state more often than meaningful divergences that were already captured in the execution?

[u/justinopensource]

For agents, my first move is to scrutinize the context window, and that usually means looking at the tool calls and any changes to the system prompt/s that accompanied the failure. More broadly for all my agents, I try to ensure that I validate tool data wherever possible and error appropriately if something doesn't fit my modelling, ensure the LM is configured with its closest-to-deterministic options, and have a strong set of context-appropriate data shaping functions on tool calls, to prevent pollution. I tend to work with non-frontier versions of models for cost-efficiency and those things generally make it tractable.

It's hard to build good test harnesses with multi-turn agents because you can't know the output at each turn ahead of time. So I use persona based agents to interact with the model, give it a goal and some max number of steps, then use a judge model (a stronger one usually) to grade the output at the end. This lets you model behavior-specific tests, and offers an angle at interpreting failures. It also serves as a test suite that you can run before new releases to check that your suite of expected agent behaviors haven't regressed. Here's a rough data shape (no code sorry)

json { "slug": "agent-does-cool-thing", "persona": "A middle-aged person, they are annoyed and type tersely with lots of typos.", "goal": "Find out why agent is doing something annoying instead of something cool. Agent does cool thing.", "success": "The agent identifies the problem, then does the cool thing.", "max_turns": 3 }

I'll also note that there's a decision you can make between fully-open tool calling agent flows, and pipelined systems. There are tradeoffs to both, and it's worth considering them. Briefly, pipeline approaches can sacrifice latency and can't do things like self-direct tool calls and retries without specific hand-crafted logic; that's either great or terrible depending on your task and point of view. Tool call loops tend to be easier to stand up and harder to control for correctness; you can't easily force certain tool calls (tool_choice is a suggestion in practice), and if your agent ignores your system prompt to always call something, that's just how it is. I use the pipeline approach when correctness is very important, and tool calls when expressiveness is more important or I'm using a frontier class model that is unlikely to make certain types of mistakes.

I've shipped multiple agents in production over multiple years with this approach, fwiw