How do you stop an agent from thrashing between replans of the same failed step?

## What thrash looks like An agent hits a deviation, replans, executes, hits the same deviation, replans again. Each plan is fluent and plausible. None of them can work, because the blocker is a fact about the world that no rearrangement of steps changes — the part is discontinued, the account lacks permission, the API the plan needs does not exist. Left alone, the agent burns its entire budget cycling, and because every cycle is *locally* reasonable, nothing in the trace looks obviously wrong until you compare attempt 1 with attempt 4 and see they are the same plan in different words. ## Why the global loop cap is not the answer Runs carry coarse backstops — maximum iterations, wall-clock limits, spend ceilings — and they will eventually stop a thrashing agent. They are the wrong instrument for three reasons. They fire long after the information needed to diagnose the problem was available, typically after 20+ wasted steps. They produce a generic exhaustion outcome that says nothing about *what* was impossible. And they cannot distinguish a productively long run from a stuck one; raising the cap to accommodate genuinely long tasks also raises the ceiling on thrash. The replan-specific control is finer: attach a counter to *the subgoal*, not the run. Step 4 has now been replanned three times. That is a specific, diagnosable condition, and three is a reasonable default ceiling — beyond it, empirically, the marginal attempt almost never succeeds where the first three failed. ## Making each attempt actually different A fresh planning call over a context that still describes the original situation produces the original plan again. Diversity has to be forced: - **Show the failures.** Each replan prompt should carry the previous attempts and the concrete reason each one failed. Without this, the model has no way to know it is repeating itself. - **Require an observable change.** The new plan must differ in a way you can check — a different tool, a different resource, a relaxed constraint, a different decomposition of the blocked step. A plan that only rewords the last one should be rejected before it executes. - **Require a stated diagnosis.** Ask the replanner to say what the last failure implies about the world before proposing the next plan. "Vendor B also has no stock, which suggests the part is discontinued rather than out of stock at one supplier" is the reasoning that turns attempt 3 into an escalation instead of attempt 4. A useful similarity check is cheap and mechanical: if the new step list is near-identical to a previous one for the same subgoal, treat that as an exhausted attempt rather than a new one. ## Escalating well When the cap is hit, what the agent hands back matters as much as the fact that it stopped. A bare "I could not complete this task" wastes the run's most valuable output — everything it learned about why the task is blocked. A good escalation payload contains: the original goal verbatim; the plan attempts, each with the step that failed and the observation that falsified it; the inferred blocker ("pump model appears discontinued across all three approved vendors"); the current world state including any side effects already committed; and, where the agent can form one, a concrete question that would unblock it ("is an equivalent replacement model approved for this site?"). That payload turns a failed run into a triaged ticket. It is also what makes capping safe: a low cap is only acceptable if what comes out at the cap is useful. ## The failure modes at both ends **Silent surrender** is the worse one. An agent that hits its limit and reports the task as done — or reports a partial result phrased as a success — corrupts everything downstream that trusts its output. Termination on exhaustion must be explicitly labelled as failure, and the run's success criteria should be evaluated independently of the agent's own claim. **Capping too aggressively** is real too. Some tasks legitimately need a second or third approach — the first vendor genuinely is out of stock and the second genuinely has it. A cap of one turns ordinary recoverable friction into escalations and trains humans to ignore the escalations. Tune per task class: routine, well-understood workflows tolerate a low cap; exploratory work needs more room. ## Distinguishing thrash from progress The cleanest discriminator is whether each attempt *learns something*. Attempt 2 that ruled out one vendor and attempt 3 that ruled out another are making progress through a finite search space, even though they look repetitive. Attempt 2 that re-proposes vendor A after vendor A already failed is thrash. Tracking which options have been eliminated — and feeding that set into the next replan — converts what looks like a loop into a search, and lets the agent conclude the space is exhausted rather than cycling in it.