Dynamic Re-planning

Re-planning is not a scheduled event but is triggered by specific signals from the environment that invalidate the current plan. Common triggers include:

• Tool execution failures (e.g., API errors, invalid outputs)
• Unexpected observations that contradict plan assumptions
• New information retrieved from a knowledge source
• Constraint violations detected by a verification step
• User intervention or mid-task instruction changes

The scope of re-planning can vary significantly:

• Local Re-planning: The agent makes a minor adjustment to the immediate next steps without discarding the overall plan. For example, retrying a failed API call with different parameters or selecting an alternative tool for a single subgoal.
• Global Re-planning: A fundamental failure or major new information causes the agent to reformulate its high-level task decomposition. This may involve generating a new sequence of subgoals from scratch, a process closely tied to meta-reasoning about strategy effectiveness.

Dynamic re-planning is not a separate module but is deeply embedded within the Thought-Action-Observation cycle. The Observation step provides the critical feedback. A dedicated Thought step then assesses this feedback, leading to either continuation or a revision. This often involves a self-reflection step where the agent critiques its past actions. The architecture must manage context to retain the original goal while discarding invalidated plan segments, a key aspect of context window optimization.

Effective re-planning requires the agent to have an implicit or explicit world model—an understanding of cause, effect, and tool capabilities (capability grounding). To decide when to re-plan, the agent employs verification steps to check action outcomes against expected results or safety rules. Mismatches here activate the error correction loop. Without robust verification, an agent may continue executing a flawed plan, a failure mode known as planetary persistence.

System design heavily influences re-planning efficiency:

• Planner-Actor Architecture: Separates a planning module (which can be re-invoked) from an execution module. This allows the high-level planner to be called anew with updated environmental state, facilitating clean-slate global re-planning.
• Hierarchical Task Networks: The agent maintains a tree of tasks and sub-tasks. Re-planning can occur at any level, allowing it to replace a failed branch while preserving successful sibling tasks, making it more efficient than full replanning.

Re-planning introduces critical engineering trade-offs:

• Latency: Each re-planning cycle consumes additional model inference time, increasing total task duration.
• Cost: More reasoning steps (Thoughts) and potential tool calls (Actions) directly increase API costs.
• Stability vs. Flexibility: Excessive re-planning can lead to indecision loops where the agent oscillates between plans. Engineers implement heuristics (e.g., max retries, confidence thresholds) and fallback mechanisms to ensure the agent eventually commits to a course of action.

An agent tasked with rerouting a shipment after a port closure demonstrates dynamic re-planning. Its initial plan (Thought: "Find fastest sea route"; Action: Query logistics API) fails when the API returns a closure (Observation: "Port X closed"). The agent re-plans by generating a new subgoal: "Find alternative port or transport mode." It may then iteratively decompose this into checking rail capacity and truck availability, dynamically building a new multimodal route. This showcases error correction loops and subgoal generation in response to real-world volatility.

A legal research agent using Retrieval-Augmented Reasoning to answer a complex query must dynamically re-plan its search strategy. An initial broad query (Action: Search case law for "fiduciary duty in mergers") may return an overwhelming number of results (Observation: 10,000 documents). The agent's meta-reasoning triggers a re-plan: "Results are too broad; need to refine by jurisdiction and date." It then generates a new, more precise tool call to the database with filters. This continuous adjustment of retrieval parameters based on observation integration is a core form of in-task re-planning.

An AI clinical assistant following a planner-actor architecture for diagnosis must re-plan when lab results contradict its initial hypothesis. Its initial plan may be to confirm Disease A by ordering Test X. However, the test result (Observation: "Test X negative") invalidates the hypothesis. The agent enters a self-reflection step: "Initial hypothesis likely incorrect. Need to consider differential diagnoses." It then dynamically re-plans by querying a medical knowledge graph for diseases with similar symptoms but different test markers, generating a new subgoal sequence for further testing. This illustrates verification steps and adaptive reasoning trajectories.

An agent using Program-Aided Language Models (PAL) to fix a bug demonstrates re-planning after execution feedback. Its first plan: generate a patch and run tests (Action: Execute test suite). The tests fail (Observation: "Test 3 fails with NullPointerException"). The agent parses the tool output, then re-plans its debugging strategy. Instead of editing the same code block, it may generate a new subgoal: "Trace the origin of the null value." This could lead to a sequence of new actions: adding print statements, checking a dataflow graph, or reviewing a related API spec—all dynamically sequenced after the initial plan failed.

An autonomous investigator agent monitoring transactions uses dynamic re-planning to pursue anomalous leads. A static rule flags a transaction (Observation: "Large transfer to new beneficiary"). The agent's initial plan may be to verify the beneficiary (Action: Query customer KYC database). If the database returns a low-risk profile, a naive agent would stop. However, an agent with meta-reasoning might re-plan: "Profile is clean, but transaction pattern is atypical for this account. Need deeper transaction history." It then dynamically generates a new tool selection to pull a 90-day history and perform network analysis, demonstrating how re-planning drives proactive investigation beyond static rules.

A customer service agent equipped with a set of tools (lookup policy, submit ticket, check status) must re-plan when a primary tool is unavailable. A user asks, "What's my refund status?" The agent's intent recognition maps this to the check_status tool. The action generation fails because the status API times out (Observation: "HTTP 504 Gateway Timeout"). The agent's fallback mechanism is triggered. It re-plans: "Primary status tool is down. Use secondary method: retrieve the ticket number via lookup_policy and inform user of delay, then queue a manual review." This shows re-planning within a tool use policy to maintain service continuity.