Debugging an Agent That Will Not Reproduce Its Own Mistake

The report said the agent had, once, deleted a config file mid task and then confidently continued, and the reruns, twenty of them, produced nothing like it. The instinct was to keep rerunning until it reproduced, which is the correct instinct for a deterministic system and a waste of compute for a probabilistic one, because the failure was not a function of the input, it was a low probability draw, and the draw had already happened exactly once. The investigation had to change shape: not "make it happen again" but "read everything about the one time it happened".

I have hit this enough times that I now check for it before I check for anything clever.

This is the debugging discipline for nondeterministic agents, and the central move is treating the single failed run's transcript as the crime scene, because it is the only place the truth exists.

This was a coding agent whose tool calls and reasoning were logged, per the sandbox's immutable transcript rule in the sandbox checklist for letting an agent touch real tools, and the logging is what made the postmortem possible at all.

Why the repro fails, precisely

A deterministic bug reproduces because the state machine is a function. An agent is a distribution over next actions, conditioned on a context that includes sampling, tool results, timing and, at temperature zero, the serving stack's own variance, per temperature zero is not deterministic. The failing run took a path whose probability may be one in a thousand, and rerunning samples the distribution again, drawing the common paths, so the absence of reproduction is expected, and tells you nothing except that the failure is rare, which you knew.

The rerun loop also has a hidden cost: each rerun is a new context, and the agent that "works fine now" proves nothing about the run that failed, because the two runs share an input but not a path. Chasing the repro is chasing a different lottery ticket.

The transcript is the repro

The failed run's transcript, the tool calls with their arguments and results, in order, is the complete record of what happened, and for an agent it replaces the core dump. The discipline is to read it as a debugger reads a stack: find the decision that produced the damage, the delete call, then walk backwards to the observation that justified it, which is usually a tool result the agent misread or an absent observation it filled with a confident assumption.

In our case the transcript showed the agent had listed a directory, received a truncated result, inferred the config was redundant, and deleted it. The truncation was the crime scene's fingerprint: a lossy observation feeding a confident inference, the same shape as the agent ran the migration twice because it misread its own log. The bug was not in the deletion, it was in the observation channel, and only the transcript showed the channel's state at the moment of the decision.

Reconstruct the context, not the outcome

The second move is to rebuild the exact context the failed run had, because the context is the input that matters, and it is larger than the task. The transcript gives it: the system prompt version, the accumulated history, the tool results, the compactions. Loading that context into a fresh session and continuing from the failing decision, a technique akin to resuming from a core dump, lets you probe the specific decision with variations, what if the list had not been truncated, and see whether the inference flips. That is a targeted experiment on the actual state, which is what the blind rerun loop could never be.

This is also where compaction matters: if the failed run had compacted its history, the transcript must include the compaction summaries, because the agent was reasoning over the summaries, not the raw turns, and reading the raw turns instead would mislead you about what the agent knew, per what an agent forgets when its context gets compacted.

Make the rare draw findable next time

Since the draw is rare, the next occurrence must be caught automatically, and the catch is a tripwire on the transcript, not on the outcome: assert invariants over the tool call stream, no delete without a preceding read of the same path, no write outside the task's directory, no credential in any argument, and alert on violation. The tripwire turns the one in a thousand draw into an immediate, fully logged incident, which converts debugging from archaeology into reading, because the alert captures the transcript at the moment of the deviation.

The tripwires are the agent's assertions, and they belong in the harness the way memory safety checks belong in a debug build: always on in the sandbox, sampled in production, and the invariant list grows by one entry per incident, which is the postmortem's durable output.

The statistics of the fix

After the fix, the question "is it fixed" is statistical, not binary. Run the task enough times to bound the failure rate at the old rate's order of magnitude, report the interval, and say honestly that a one in a thousand draw needs thousands of runs to disprove, which is expensive, so lean on the tripwire: with the invariant asserted, the failure mode is impossible by construction rather than improbable by sampling, and impossible is the only "fixed" a probabilistic system can honestly claim.

If it happens again

A nondeterministic agent's failure is a draw, not a function, so the rerun loop is the wrong instrument and the single failed transcript is the repro. Read the tool call stream backwards from the damage to the observation that justified it, reconstruct the exact context including compactions to probe the decision, and convert the rare draw into a caught one with tripwires over the tool stream.

The agent will not reproduce its mistake for you. It already gave you everything you need, once, in the transcript, and the discipline is to treat that one run as the complete evidence, because for a probabilistic system, the crime scene is the only witness, and it only speaks once.