Is reactive planning the opposite of planning ahead?

No. Responses can be planned or programmed ahead of time and selected according to conditions during execution.

Is it identical to reactive control?

The ideas overlap. Reactive planning emphasizes goal-directed action structures, while reactive control is the broader notion of feedback-sensitive action selection and adjustment.

Can a reactive plan handle every surprise?

No. Its coverage and assumptions limit what it can handle, and some changes require additional planning or intervention.

AI Glossary / Graphs and symbolic AI / Intermediate

Reactive planning

Definition

Reactive planning organizes goal-directed behavior so that the next action depends on the situation encountered during execution. Instead of treating a plan only as one fixed sequence, it can represent conditional responses, procedures, or policies that remain sensitive to change. The term covers several approaches; it does not name one universal algorithm or guarantee successful behavior in every unpredictable environment.

What it means

A conventional action list says what should happen next if events follow the expected course. A reactive plan also addresses what to do when the relevant conditions differ. That may mean continuing, skipping a step already achieved, recovering a lost condition, or choosing another applicable procedure.

Planning can still happen in advance. The reactive part concerns how the resulting structure is used when the world changes. Generating a new plan after every observation is one possible design choice, but reactive execution can also use responses that were already prepared.

How it works

Specify a goal, relevant conditions, and available actions. A planning or programming process links situations to actions intended to make progress. During execution, observations determine which part of that structure applies.

Schoppers' universal-plan research is an early example: the plan encodes goal-directed responses to anticipated situations, and execution selects a response from the current situation. Nilsson's teleo-reactive programs provide another representative mechanism using prioritized conditions and actions, with conditions continually reconsidered.

Neither example licenses an assumption that any informal rule set covers every possible event. Coverage, termination, conflicting rules, sensing limitations, and recovery need examination in the particular system. A broader architecture may combine reactive execution with deliberation when the prepared responses no longer fit.

Three practical examples

Simulated assembly: a plan checks whether a part is already positioned before attempting to move it again.
Software workflows: an execution plan checks whether a required file exists and is current before deciding to create, validate, or use it.
Game agents: a character's goal-directed procedure changes its immediate action when access to an object or location changes during play.

Think of it this way

Think of preparing a checklist that asks about current conditions instead of blindly advancing a bookmark. If the required item is already present, the checklist can skip obtaining it; if it has disappeared, the relevant step becomes active again. This captures conditional execution. It does not establish that a checklist can solve every unexpected problem or that repeated checking is free of cost.

Worked example

Consider a toy file-preparation task with the goal “a current report is archived.” The environment has three conditions: a current source file exists, a report from that source exists, and that report is archived. Use the following priority structure:
If the current report is archived, finish.
Otherwise, if the current report exists, archive it.
Otherwise, if a current source exists, generate the report.
Otherwise, obtain a current source.

Starting with none of these conditions true, normal execution obtains the source, generates the report, and archives it. Now suppose another authorized process generates the report after the source is obtained. At the next check, the second rule applies and the generation step is skipped. The plan takes advantage of a condition achieved elsewhere.

Conversely, suppose the source changes before archiving. The previous report is no longer current, so the conditions must reflect that change and the generation rule becomes relevant again. A rule that checked only whether any report file existed would miss this dependency.

The example depends on accurate version information and defined action behavior. If the source changes continually, completion may be postponed indefinitely. Conditional responsiveness does not by itself prove that the goal will eventually be reached.

Illustrative case study

Fictional case: Rowan Reports develops an assistant for an internal document workflow. The original version follows obtain, generate, archive in a fixed order and unnecessarily regenerates reports completed by another process.

The revised design tests explicit completion conditions and source versions before each action. Reviewers examine cases in which work is already done, a report disappears, or its source becomes outdated. They also check that repeating an interrupted operation does not create unintended duplicate effects.

This fictional case demonstrates design questions for conditional execution. It does not describe an actual deployment, guarantee that archival operations are reversible, or report a measured productivity increase.

Common misconceptions and mistakes

Do not assume reactive planning eliminates the need for a model. Conditions must still capture facts relevant to the task, such as the distinction between an existing report and a current report.

Do not equate reacting with generating a completely new plan. Some systems respond by selecting another branch of an existing structure.

Avoid overlooking actions already in progress. Switching a high-level choice does not automatically cancel a lower-level operation cleanly. Also distinguish recovery from endless repetition: an agent can keep trying an applicable action without making progress. A well-described system explains what happens when its prepared responses fail.

Business use

For a business workflow, ask which changes the system is designed to handle and how it verifies the effects of its actions. Request explicit definitions of completion, freshness, and recovery conditions.

In the worked example, freshness is central to correctness. A system that reacts quickly to an outdated condition can archive the wrong report faster. Useful review evidence therefore includes traces of condition changes and action choices, not merely average execution time. Teams should also decide when repeated failure requires a different procedure or human attention.

Check your understanding

Why does the toy plan need to distinguish a current report from any report?

Answer: A report can exist but no longer match the source. Without that distinction, the system may archive an outdated result.

Related terms

Conditional plan
Policy
Execution monitoring
Reactive control
universal plan
teleo-reactive program
replanning
goal condition

Learn next

trace the file example under a missing input, an already completed output, and a changed source version. Identify which condition must change in each case. Then study the difference between selecting a prepared response and searching for a new plan.

Sources

Primary sources: M. J. Schoppers, “Universal Plans for Reactive Robots in Unpredictable Environments”: https://www.ijcai.org/Proceedings/87-2/Papers/096.pdf Nils J. Nilsson, “Teleo-Reactive Programs for Agent Control”: https://arxiv.org/pdf/cs/9401101 Relevant representation and execution passages were read. These are representative approaches, not interchangeable definitions. The workflow and Rowan Reports case are original.

Previous: Reactive layer Next: Read noise