Replanning

Replanning is initiated when a primitive action in the current plan fails during execution. This failure can be due to unmet preconditions, unexpected action effects, or external interference. The system must detect the failure, assess the new world state, and initiate a new planning cycle from the current state, not the initial state.

• Example: A delivery robot's path is blocked. The 'Navigate' action fails, triggering replanning to find an alternative route from its current location.

The core mechanism involves re-invoking the HTN decomposition process. The planner takes the current, unexpected world state and the remaining compound tasks from the failed plan as a new initial task network. It then applies decomposition methods valid for the new state to generate a new hierarchical plan.

• This is distinct from simple plan repair; it often requires re-solving the problem from a higher abstraction level, not just patching a sequence of actions.

Replanning systems tightly couple the planning and execution phases in a closed loop. This is a hallmark of online, real-time planning. The system does not generate a complete, static plan upfront but rather plans a few steps ahead, executes, monitors, and replans as needed.

• This architecture is essential for handling dynamic environments where the state can change due to other agents or stochastic events.

HTN-based replanning is more efficient than replanning from scratch with classical planners. The hierarchical structure and task libraries provide domain-specific knowledge that constrains the search space. The planner can often reuse successful decompositions from higher-level tasks, only re-planning the failed subtree.

• This leverages the skeletal plan from the previous attempt, focusing computational effort on the problematic part of the task network.

Replanning often occurs in contexts of partial observability, where the agent's sensors provide an incomplete or noisy picture of the world. Execution failure reveals new information. The replanning process must integrate this updated belief state, which may involve reasoning about conditional tasks and probabilistic outcomes.

• Example: A diagnostic agent finds one component is not faulty, triggering replanning to test the next most likely component in the hierarchy.

Replanning is not an error condition but a fundamental feature of robust, autonomous agents. It transforms a brittle, open-loop executor into a resilient, closed-loop system capable of recovering from setbacks and adapting to change. This capability is a key differentiator for agents operating in enterprise environments like logistics, robotics, and automated customer support.

• It directly enables recursive error correction and is a prerequisite for long-horizon task execution.

The continuous process of observing the execution of a plan and comparing the expected world state (predicted by the plan's effects) with the actual observed state. This is the primary trigger for replanning. A discrepancy or execution failure (e.g., a precondition for the next action is not met) signals the need to generate a new plan. Effective monitoring requires a world model and sensor integration to detect deviations.

A lightweight alternative to full replanning where the system attempts to locally modify the existing, failing plan rather than generating a new one from scratch. Techniques include:

• Action substitution: Replacing a failed action with a different one that achieves the same subgoal.
• Plan splicing: Inserting a new sequence of actions to re-establish a required precondition.
• Ordering relaxation: Changing the temporal order of remaining actions. Repair is often faster but may lead to suboptimal plans if the fault is fundamental.

The event that directly necessitates replanning. It occurs when a primitive action cannot be executed. Common causes include:

• Precondition violation: The world state does not satisfy the action's required preconditions.
• Exogenous event: An unexpected change in the environment invalidates the action's context.
• Resource unavailability: A required tool, API, or physical resource is inaccessible.
• Runtime error: The action's execution results in an exception or error code. The agent must classify the failure type to inform the replanning strategy.

A planning paradigm characterized by tight coupling between sensing and acting, where plans are generated or selected in real-time in response to environmental changes. Unlike classical planning which generates a complete plan upfront, reactive systems often use:

• Condition-action rules (production systems).
• Subsumption architectures.
• Behavior trees. Replanning in a reactive context is frequently a matter of triggering a different set of pre-defined behaviors rather than complex re-decomposition.

The proactive generation of alternative plans (branching paths) at decision points where the outcome of an action is uncertain. This creates a plan tree where each branch is a contingent response to a possible future state. During execution, the agent follows the branch corresponding to the observed outcome. This reduces replanning latency but increases upfront computational cost and plan storage. It is a form of planning for flexibility.

The higher-level cognitive process where the agent reasons about its own planning and replanning. This involves deciding whether to replan, when to trigger it, and how much computational effort to allocate. Key questions include:

• Is the failure transient or permanent?
• Will replanning likely succeed given the new constraints?
• Should the agent attempt a simple repair or a full re-decomposition? This self-monitoring layer is essential for building robust, resource-aware autonomous systems.