When should an agent backtrack to an earlier step rather than repair the failing one?

## The direction of a repair Most repair thinking is *forward*: the step at position N failed, so fix position N and continue. Backtracking is the *backward* move — concluding that the real defect sits at position K < N, invalidating it, and re-deriving everything from K onward. It is the difference between fixing the symptom and fixing the cause, and it is the mode agents most often skip. ## When the evidence points backward The telltale signature is a contradiction between two observations rather than a plain failure. Step 2 said the bearing is failing; step 6's on-site measurement says vibration is nominal. Nothing errored. Both cannot be true, and the newer observation is generally the better-grounded one, so the older result becomes the suspect. Other common triggers: a retrieval step returned documents that later turn out to be the wrong revision; an extraction step produced a plausible but wrong number that three downstream calculations consumed; an early exploratory branch committed the plan to an approach that later evidence shows was never viable. Contrast this with an ordinary local failure — a tool returns an error, a vendor has no stock — where the cause is clearly at the failure point and forward repair is correct. Backtracking is for *poisoned inputs*, not for failed actions. ## What the plan must carry for backtracking to be possible **Provenance.** Each step's inputs should record which earlier step produced them. Without that, "which upstream result poisoned this?" is an open-ended reasoning problem the model answers by guessing. With it, the agent walks the dependency edges from the contradicted fact to its source and knows exactly what to invalidate and exactly which steps consumed it. **Re-runnability.** The target step has to be safe to execute again. Read-only steps — a query, a sensor poll, a retrieval, a diagnostic — are idempotent and free to re-run. Steps with side effects are not. This is where agent backtracking diverges hard from search-tree backtracking in classical planning or Tree-of-Thoughts-style reasoning: abandoning a branch in a search tree costs only the compute spent on it, while abandoning a branch in an agent that has already ordered a part, opened a ticket or paged an engineer has left permanent marks on the world. The practical consequence is that **irreversible steps act as barriers**. Once the agent has dispatched a technician, it cannot cleanly return to a state before the dispatch; it can only repair forward, possibly with explicit compensating actions. Some teams exploit this by deliberately front-loading reversible, information-gathering steps and deferring irreversible commitments as late as possible in the plan — which keeps the backtrackable region large for as long as possible. ## Recording the abandoned branch When an agent backtracks, the discarded path must not be silently forgotten, or the fresh derivation from step 2 will happily reproduce the same reasoning and walk into the same wall. Carry forward a compact note of what was tried and why it was abandoned — "the vibration-based bearing diagnosis was based on a reading taken before the last service and contradicted on site; do not re-derive from that reading." This is the same discipline as recording a failed hypothesis: the value is in not re-exploring it. ## Cost and when not to bother Backtracking is the most expensive repair mode in wall-clock terms, because it re-executes work that already ran. Re-running a diagnostic that takes forty minutes to reach a decision the agent could have reached by repairing forward is a poor trade. Weigh it by how much of the plan is actually contaminated: if a single downstream step consumed the bad value, correcting that value in place and re-running just that step is cheaper and equivalent. Backtracking earns its cost when the poisoned result is load-bearing for a substantial part of the plan, or when continuing on it risks an expensive or unsafe action. ## Depth limits Unbounded backtracking is its own failure mode: an agent that keeps stepping further back on each contradiction can consume a run without ever making forward progress. Bound it — a small number of backtrack levels, or a rule that you may backtrack only to the nearest producing step of the contradicted fact rather than to arbitrary earlier points. When the bound is hit, the honest move is to surface the contradiction to a human with both observations attached, rather than to keep re-deriving. ## The senior framing Backtracking is dependency-graph reasoning applied to an agent's own history. It requires that the history be *structured* — steps, their outputs, and who consumed what — not just a flat transcript of messages. Teams that keep the plan as an externalized artifact with recorded inputs and outputs get backtracking almost for free; teams whose plan lives only inside a chat history usually cannot do it at all.