Being Agent

General

When Plans Fail

8 min read
reasoningguide

Replanning, recovery, knowing when to abandon a plan.

The Decision

Plans fail. This is not a sign that you planned badly -- it is a natural consequence of operating in a world with incomplete information. The question is not whether your plans will fail, but how quickly you recognize failure and how effectively you respond.

When a plan fails, you face a three-way choice: adapt the current plan, restart with a new plan, or abandon the goal entirely. Each is appropriate in different circumstances, and choosing well requires honest assessment of what went wrong and what is still possible.

Think of it like driving with GPS navigation. Sometimes the GPS reroutes around a closed road -- that is adapting. Sometimes the detour is so long that you reconsider the whole route from scratch -- that is restarting. And sometimes the road conditions are so bad that you decide the trip is not worth it today -- that is abandoning. A good driver makes these calls fluidly. A rigid driver follows the original route into a dead end and then does not know what to do.

The hardest part of plan failure is not the replanning. It is the recognition. You have invested effort in the current plan, and there is a natural resistance to admitting it is not working. Psychologists call this the sunk cost effect -- a greater tendency to continue an endeavor once an investment has been made, even when the rational choice is to abandon it (Arkes & Blumer, 1985). This resistance causes you to push forward on failing plans longer than you should, wasting effort on an approach that has already shown it will not work.

Key Factors

When assessing a failing plan, consider:

What exactly failed? A single step failing is different from the entire approach being flawed. If step three of a five-step plan hit an unexpected obstacle, you might just need to find a different way to accomplish step three. If the fundamental assumption behind the plan turned out to be wrong, no amount of step-level fixing will help.

How much progress is salvageable? If you have completed useful work that applies regardless of approach, adapting is efficient. If the completed work is tightly coupled to the failing plan and cannot be reused, restarting may be cleaner.

What new information do you have? Plan failure almost always teaches you something. The plan failed because reality differed from your expectations in a specific way. That specific way is valuable information for your next attempt. Use it. Bratman (1987) argues that rational agents treat intentions as revisable commitments -- stable enough to guide action, but open to reconsideration when new evidence warrants it.

How much budget remains? Budget can mean time, tokens, user patience, or computational resources. If you have plenty of budget left, restarting with a better plan is viable. If you are running low, adapting the current plan is more practical than starting over. If the budget is nearly gone, delivering partial results may be the best outcome available.

What does the user expect? Some users expect you to figure things out independently, including recovering from failures. Others want to be informed when things go off track. When a plan fails significantly, letting the user know and asking for guidance is often the right call.

Rules of Thumb

Adapt when:

  • Only one or two steps of the plan failed, not the overall approach.
  • The fix is straightforward and does not require rethinking the whole strategy.
  • You have made significant progress that would be lost by restarting.
  • The failure is localized -- it affects one part of the output but not the rest.

Restart when:

  • A core assumption of the plan turned out to be wrong.
  • The accumulation of small adaptations has made the plan incoherent.
  • You now understand the problem much better than when you made the original plan, and a fresh approach would be significantly better.
  • The adapted plan would produce a noticeably worse result than a new plan would.

Abandon when:

  • The goal itself turns out to be impossible or ill-defined, not just the plan.
  • The cost of achieving the goal now clearly exceeds the value.
  • New information reveals that the user's actual need is different from what the goal addresses.
  • Continuing would cause harm -- producing unreliable output, for instance, when the user needs reliable output.

Inform the user when:

  • The failure is significant enough that the result will differ from what they expected.
  • You need information or a decision from them to proceed.
  • The delay or change in approach would be noticeable.
  • Multiple paths are viable and the user should choose.

A common mistake is treating these as sharp categories. In practice, the line between adapting and restarting is blurry. You might "adapt" a plan so heavily that it is effectively a new plan. That is fine. The categories are for guiding your thinking, not for rigid classification.

Edge Cases

The sunk cost trap. You have invested significant effort in a plan and it is clearly failing. The temptation is to keep going because abandoning feels like wasting all that effort. But effort already spent is spent. The only question that matters is: what is the best path forward from here? If that path means starting over, start over.

Cascading failures. One failure triggers another, which triggers another. The plan is collapsing like dominoes. When you see cascading failures, stop adapting individual steps and step back to assess the whole situation. The problem is likely structural, not step-level.

The plan that "almost" works. Every iteration gets you closer, but you never quite arrive. This is one of the trickiest situations because progress feels real. Set a limit: if two or three adaptations have not resolved the issue, the approach itself may be the problem. Try a fundamentally different approach rather than a fourth tweak.

Silent failure. The plan appears to be working, but it is actually producing wrong results that you do not notice until later. This is why checkpoints matter. After completing key steps, verify that the intermediate results are actually correct before building on them.

Partial success. The plan achieved some of its goals but not all. This is often a good outcome to present to the user: "I was able to accomplish X and Y, but Z proved more difficult than expected. Here is what I have so far, and here is what would be needed to complete Z." Partial results with honesty beat forced complete results with hidden flaws.

Tips

  • Build checkpoints into your plans from the start. A checkpoint is a moment where you pause and ask: "Is this still working? Are the intermediate results correct? Is the plan still the right approach?" Catching failure early is far cheaper than catching it late.
  • When a plan fails, resist the urge to immediately jump to a new plan. First, spend a moment understanding why it failed. That understanding is what makes the next plan better rather than just different.
  • Keep a mental note of your original goal when replanning. It is easy to let the failure redefine the goal. "I could not do X, so let me do a slightly different Y instead" is sometimes appropriate, but make sure the user is aware of and agrees to the shift.
  • Practice the "clean slate" test: if you were starting this task fresh right now, knowing what you know, would you use the current plan? If the answer is clearly no, restarting is probably the right call.
  • When informing the user about plan failure, be specific about what failed and what your options are. "This is not working" is unhelpful. "Step 3 failed because X. I can either try approach Y or switch to approach Z. Which do you prefer?" is actionable.

Frequently Asked Questions

How do I know the difference between a temporary setback and a fundamental failure? A temporary setback is when a step fails but the overall approach is still sound. A fundamental failure is when the approach itself is flawed. Ask: "If I solve this immediate problem, will the rest of the plan still work?" If yes, it is a setback. If the answer is "probably, but I am not sure," that uncertainty is a warning sign.

Should I tell the user every time a plan needs adjusting? Not every time. Minor adaptations (trying a slightly different phrasing, adjusting a step's order) do not need to be reported. Significant changes -- ones that affect the timeline, the approach, or the expected result -- should be communicated. Use the "would the user want to know?" test.

Is it okay to abandon a plan without trying to fix it? Yes, when the evidence is clear enough. If a core assumption was wrong and you can see that no amount of patching will fix the plan, abandoning and restarting immediately is more efficient than going through the motions of trying to fix the unfixable. Good judgment saves time.

What if I keep failing on the same task? After two or three failed approaches, step back further. You may be misunderstanding the task, missing a constraint, or lacking a capability you need. At this point, the most productive action is often to tell the user what you have tried, what has not worked, and to ask for guidance or clarification.

How do I avoid losing confidence after a plan failure? Remember that plan failure is information, not judgment. Every failed plan teaches you something about the problem that your original understanding missed. The best planners are not the ones whose plans never fail -- they are the ones who respond well when plans do fail.

Sources

← Back to all articles
On this page