Planning › Plan Revision and Recovery

The most practically important aspect of planning is handling the gap between the planned sequence and what happens during execution. Plans fail, observations surprise, new information changes what is optimal. A resilient planning agent does not give up when this happens. It revises.

Here planning systems earn their value. A system that can generate a plan but cannot recover from failures offers little improvement over a system that executes blindly step by step. Recovery capability justifies the overhead of upfront planning because it turns a failure from a dead end into a detour. The structured representation of the plan makes recovery reasoning tractable: the agent knows exactly what has been accomplished, what was expected next, and what the ultimate goal is, which is precisely the information needed to chart a new course.

Three conditions should trigger replanning:

Execution failure: A step fails and cannot be completed despite retries and reformulation attempts. The plan must be revised to find an alternative path to the goal that does not depend on the failed step. This might mean finding a different tool that provides the same information, reformulating the goal in a way that does not require the unavailable resource, or acknowledging that the original goal cannot be fully achieved and proposing a partial completion.

Observation surprise: A step completes but its output is qualitatively different from what the plan assumed. For example, the plan assumed a document would contain information about a topic, but the retrieved document does not. Steps downstream that depend on this information need to be revised or replaced. Observation surprises are more subtle than execution failures because the step appears to succeed, but the success is hollow: the output is not what the plan needed.

Goal clarification: During execution, the agent realizes that the original goal specification was ambiguous and its interpretation was wrong. The plan needs to be rebuilt around the corrected understanding of what success looks like. Goal clarification is particularly important in multi-turn agent interactions where the human user provides feedback during execution that reveals the agent's initial understanding was incomplete.

When a trigger is detected, the agent has several options for how to replan, ranging from minimally invasive local repair to complete plan reconstruction. The right choice depends on how severe the trigger is and how much of the existing plan remains valid.

Local repair modifies only the steps immediately affected by the failure, leaving the rest of the plan intact. If step four fails because a specific database is unavailable, a local repair replaces step four with a call to an alternative database. This is efficient because the planner does not need to regenerate the entire plan. The context window cost is low, the latency is minimal, and the risk of introducing new errors into the unchanged parts of the plan is zero. Local repair is the right first response to most execution failures and observation surprises.

Suffix replanning abandons the remaining steps of the plan and generates a new plan for the remaining subgoal, starting from the current state. The planner is given the original goal, the steps already completed and their outputs, and asked to generate a plan for what remains. This is more expensive than local repair but handles cases where the failure fundamentally changes the approach needed for subsequent steps. If step four's failure reveals that the entire approach to the second half of the plan is wrong, local repair to step four is insufficient; the whole suffix needs to be rebuilt.

Full replanning restarts the planning process from scratch given what has been learned. This is the most expensive option but is appropriate when the plan's underlying assumptions have been invalidated entirely. Full replanning benefits from the information gathered during the failed execution: the planner now knows what does not work and can avoid those paths. It should explicitly include a summary of prior failed attempts in the planning prompt so the new plan is informed by what was learned.

In practice, most implementations try local repair first, escalate to suffix replanning if local repair fails twice, and use full replanning only as a last resort. This escalation policy minimizes the average replanning cost across all executions while ensuring that severe failures eventually trigger a full response.

Reflection-based replanning (as in the Reflexion framework by Shinn et al., 2023) adds a systematic self-critique step before replanning. After a plan failure, the agent is prompted to reflect on what went wrong: what assumption failed, what information was missing, what strategy was flawed. This reflection is stored in a "working memory" of past failures and consulted at the start of the next planning attempt, helping the agent avoid repeating the same mistake.

The key insight behind Reflexion is that the gradient signal in traditional machine learning, which pushes model weights toward better performance, can be replaced for LLM agents by a verbal gradient: a natural language description of what went wrong and what to do differently. This requires no weight updates and can be implemented entirely through prompting, making it immediately applicable to any LLM without fine-tuning.

To make this concrete, consider an agent that tries and fails to answer a multi-hop research question. The standard approach is to restart from scratch. Reflexion instead instructs the agent to generate a short critique like "I assumed the primary source contained the answer, but it did not. Next time, I should verify the source topic before relying on it." This critique is prepended to the next attempt's planning prompt. The model reads its own past failure analysis and uses it as a prior when generating the new plan, systematically avoiding the strategy that failed.

Across multiple attempts, the agent accumulates a growing library of failure modes specific to this task, and the planning quality improves trial by trial without any change to model weights. The Reflexion paper demonstrated that this approach could solve tasks that pure execution loops could not, by systematically eliminating strategies that had already proven to fail. The limitation is that the failure memory accumulates only within a single task session; it does not generalize across different tasks or persist beyond the current conversation.

A subtle aspect of recovery that is often overlooked in simple implementations is the role of uncertainty. Not all plan failures are equally surprising. A step that depended on a source known to be occasionally unavailable should trigger a different response than a step that failed for a completely unexpected reason.

Well-designed planning agents maintain explicit uncertainty estimates about which steps are likely to succeed. Steps that depend on unreliable tools, ambiguous inputs, or volatile external state should be flagged as high-risk during planning, and contingency branches should be pre-planned for them. This is analogous to how a careful human planner identifies the riskiest parts of their plan and thinks through fallbacks before starting execution. If the database query might return empty results, plan for it now rather than discovering it mid-execution with no fallback ready.

Uncertainty-aware planning is harder to implement but significantly more resilient in practice. The simplest implementation asks the model to annotate each step in the plan with a confidence score and a fallback action. The executor checks the confidence score before each step and pre-allocates resources for the fallback if the confidence is below a threshold. More sophisticated implementations model uncertainty as probability distributions over step outcomes and use expected value calculations to choose between plan variants.