How does plan monitoring differ from action monitoring?

It considers the remaining plan, while action monitoring focuses on immediate prerequisites.

Can a monitor determine that a plan will succeed with certainty?

Only within sufficiently strong assumptions; real-world uncertainty can limit that conclusion.

Does a failed plan require starting over?

Not always. A valid prefix or reusable work may be retained while the remaining portion is repaired.

AI Glossary / MLOps and deployment / Intermediate

Plan monitoring

Definition

Plan monitoring is checking whether the remaining part of an agent's current plan can still achieve its intended goal given the latest relevant information. In automated planning, it looks beyond the prerequisites of the next action to consider the continued viability of the planned sequence. A plan may need revision even when its next action is still possible.

What it means

A plan links actions through assumptions about resources, conditions, and expected effects. Changes in the environment can invalidate a later step without immediately preventing the next step.
For example, a robot may still be able to pick up a package even though the planned destination has become unavailable. Checking only pickup conditions would miss the problem with the remaining delivery plan.
Plan monitoring asks about achieving the current goal through the remaining plan. Goal monitoring asks a different question: whether that goal should remain the preferred objective. Neither kind of monitoring guarantees success when observations or the environment model are incomplete.

How it works

Maintain the current state estimate, the unexecuted portion of the plan, and the conditions relevant to its completion. Update the state using observations and information about external changes.
Assess whether the remaining actions still have a valid route to the goal under the planning model. This can involve checking later prerequisites, resource availability, timing, or expected consequences. The method and effort depend on the planning representation and the task.
If the plan no longer works, the response may be to repair a suffix, insert a recovery action, choose another route, or request a new plan. If evidence is uncertain, gathering information may be preferable to immediately abandoning the plan. Monitoring identifies the issue; the response mechanism decides what change is permitted and useful.

Three practical examples

A warehouse agent can detect that a reserved storage location became unavailable before spending time transporting an item there.
A data workflow can recognize that a downstream processing service will be unavailable during its scheduled run, even though extraction can still start.
A scheduling system can reassess whether the remaining tasks still fit a deadline after one completed task takes longer than expected.

Think of it this way

Think of checking the rest of a hiking route after learning that a bridge farther ahead is closed. The next stretch of path is walkable, but following it may no longer lead to the destination as planned. The analogy captures looking beyond the immediate action. An automated system additionally needs explicit state, uncertainty, and rules for evaluating alternatives.

Worked example

Consider an invented delivery plan with three remaining actions: collect a parcel in two minutes, travel to a pickup desk in six minutes, and hand it over in one minute. It is now 10:00, and the desk closes at 10:12. Under the fixed-duration assumptions, the plan finishes at 10:09 and is feasible with three minutes of margin.
A new verified notice says the desk will close at 10:07. The parcel is still available and the carrier can still collect it, so the next action's immediate prerequisites remain satisfied. However, the planned handover would occur after closure.
Plan monitoring detects that the remaining nine-minute sequence no longer meets the desk's availability condition. Suppose an authorized alternate desk stays open until 10:20 but requires nine minutes of travel after collection. The revised plan takes 2 + 9 + 1 = 12 minutes and finishes at 10:12, within that alternate desk's window.
This does not mean every monitor automatically chooses the alternate route. The system must check that the alternate desk accepts the parcel and that the changed route is permitted. It must also consider uncertainty in travel time if the durations are not reliable.
The example separates three checks: collection is currently possible, the original remaining plan fails its timing condition, and a candidate replacement appears feasible under stated assumptions.

Illustrative case study

In a fictional analytics project, an automated workflow begins preparing data for a scheduled model run. A notice arrives that the required downstream compute environment will be unavailable before training can finish.
The workflow checks its remaining plan and avoids continuing solely because the next preparation step is executable. It follows a defined policy to preserve completed work and reschedule the dependent steps.
The case illustrates how plan monitoring can prevent work that would lead into a known blockage. It does not imply that every partial task should stop; reusable preparation may still be worthwhile under the workflow's priorities.

Common misconceptions and mistakes

Do not confuse a valid next action with a valid remaining plan. Later dependencies can already be impossible.
Do not assume plan monitoring proves the future. Its conclusion depends on the model, observations, and uncertainty assumptions.
Do not confuse repairing a plan with changing the goal. A route can change while the objective remains the same.
Do not spend unlimited effort rechecking every possible contingency when the task cannot justify that cost. Monitoring design should focus on relevant conditions and decision points. Also, a detected blockage does not automatically authorize a workaround outside the agent's allowed scope.

Business use

Plan monitoring is useful when multi-step work depends on resources or conditions that can change during execution. It helps teams identify which future dependencies need current information and which changes should interrupt the workflow.
Operational records should capture the condition that changed, the affected future step, and the chosen response. This makes it easier to distinguish model errors, external disruptions, and inappropriate recovery decisions. The practical aim is to maintain a viable path to the intended outcome without blindly executing a stale sequence.

Check your understanding

A parcel can still be collected, but the destination will close before arrival. Which monitoring level catches the problem with continuing the original sequence?

Answer: Plan monitoring, because the issue concerns a later condition needed for the remaining plan to achieve its goal.

Related terms

Execution monitoring
Action monitoring
Goal monitoring
Precondition
replanning
plan repair
temporal constraint
and state estimation

Learn next

Write a three-step plan with a deadline or shared resource. Introduce a change that leaves the next action possible but invalidates a later step. Describe the observation needed to catch it and a permitted response.

Sources

Sources: Russell and Norvig, Artificial Intelligence: A Modern Approach, fourth-edition teaching slides, Chapter 11, slide 19, university-hosted publisher material: https://zoo.cs.yale.edu/classes/cs370/lectures/slides/chapter11_4e.pptx.pdf

Previous: Plan-and-solve Next: Plan recognition