II · Planning & Control FlowMature★★

Replan on Failure

also known as Adaptive Replanning, Plan Revision

Trigger a fresh planning step when execution evidence contradicts the current plan.

This pattern helps complete certain larger patterns —

  • used-byOuter-Inner Agent Loop·— Run two nested loops: an outer planner agent decomposes the goal into subtasks; an inner executor runs a ReAct loop on each, and the outer can replan based on the inner's progress.

Context

A team runs a Plan-and-Execute agent where the planner commits to a plan up front and the executor walks it step by step. The world is not perfectly predictable: a tool returns an error, an observation contradicts an assumption in the plan, or an observer disagrees with where the run is heading. The team wants the agent to repair the plan from that evidence instead of grinding through to failure.

Problem

Plans are made under incomplete information, so some plans are wrong from the start and others become wrong partway through. Without a replanning step the executor will either keep trying the same broken sequence until the step budget runs out, or it will silently fail and return partial results that look complete. A naive replan-on-every-error policy thrashes — the agent re-plans, fails, re-plans again on the new plan, and never makes progress. The team needs explicit triggers that decide when failure is bad enough to send control back to the planner with the failure context attached.

Forces

  • Replanning resets cost; thrashing is real.
  • When to trigger replanning is itself a judgment.
  • Stale context: the new plan must include lessons from the failed run.

Example

A travel-booking agent has a plan that assumes a particular hotel API is up; the API returns 500 on every retry. Without replan-on-failure the agent grinds the same dead branch until budget exhausts. Instead, the tool error trips a replan trigger: the planner is invoked again with the failure context, drops the dead branch, picks an alternate provider, and proceeds. The user sees one extra second of latency and a successful booking instead of a timeout.

Diagram

Solution

Therefore:

Define replan triggers (tool error, unexpected observation, observer dissent). When triggered, the executor pauses and the planner runs again with the failure context. The new plan replaces the old one; partial progress is preserved if compatible.

What this pattern forbids. The executor cannot deviate from the current plan without raising a replan request.

The smaller patterns that complete this one —

  • usesPlanner-Executor-Observer★— Add an explicit Observer role between Planner and Executor so progress is checked against the plan instead of trusted blindly.

And the patterns that stand alongside it, or against it —

  • complementsPlan-and-Execute★★— Plan all the steps once with a strong model, then execute each step with a cheaper model under the plan.
  • complementsException Handling and Recovery★★— Catch and react to predictable failure modes (tool errors, rate limits, validation failures) with structured recovery paths.
  • alternative-toErrors Swept Under the Rug✕— Anti-pattern: scrub failed actions, stack traces, and error observations from the agent's own context so the trace looks clean, leaving the model with no evidence of what did not work.
  • complementsSingle-Path Plan Generator★★— Generate one linear sequence of intermediate steps from current state to goal — the lightweight planning alternative to tree-of-thoughts and multi-path generation.
  • complementsIncremental Model Querying★★— Generate plan steps by sequentially querying the model at each step rather than producing the whole plan upfront in one call.
  • complementsPlanner-Executor-Verifier (PEV)★— Triadic specialization where a planner produces the plan, an executor runs it, and a separate verifier checks each step's effects against the original goal.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance