Planning and Replanning
How an AI System Turns a Goal Into Steps and Changes Course When the World Disagrees
A Goal Is Not Yet a Procedure
A user may give an agent a goal rather than a complete sequence of commands:
The system must somehow move from that desired outcome to useful intermediate work.
A plan is a proposed route from the current state toward a goal.
A Plan Is Not the Future
A plan describes what the system currently expects or proposes to do. It does not establish that those events will occur.
The world may disagree. A permission may be denied. A tool may fail. New evidence may make later steps unnecessary. A human may redirect the task.
Therefore a plan should be treated as working state, not prophecy.
What Goes Into Planning?
Desired Outcome
What would count as completion?
What Is Known Now?
Current observations, previous results and unresolved questions.
What Must Not Happen?
Read-only rules, cost limits, deadlines, safety boundaries and user instructions.
What Can Be Attempted?
Available tools, agents, data sources and permissions.
From Goal to Subgoals
The server mission can be decomposed:
↓
IS HOST REACHABLE?
↓
IS SERVICE RUNNING?
↓
IS PORT LISTENING?
↓
WHAT DO LOGS / CONFIG TESTS SHOW?
↓
VERIFY LIKELY CAUSE
↓
REPORT
This resembles familiar human troubleshooting because the model has encountered many patterns of decomposition during training and post-training. The generated plan is still model output—not a hidden symbolic program automatically guaranteed to be correct.
Planning Can Be Explicit or Implicit
A system might generate a visible structured plan:
2. Check service status.
3. Inspect logs if service is failed.
4. Run non-destructive configuration test.
5. Compare evidence and report.
Or it may choose only the next useful action and plan incrementally as results arrive.
Many practical agent systems mix both approaches: maintain a coarse plan while deciding details step by step.
The Plan Lives in State
A plan may exist as text in model context, structured orchestrator state, a task graph, database records, or some combination.
It is not necessarily stored in model weights, and it is not necessarily present in every agent's context.
This connects directly to Page 32: plan state is another form of task/agent state.
Dependencies Shape the Plan
Some steps cannot sensibly happen before others.
Dependency: identify correct host/service first.
Need: synthesize final diagnosis.
Dependency: obtain sufficient evidence first.
Planning therefore creates a dependency structure, not merely a numbered list.
Some Work Can Be Parallel
Other tasks are independent enough to run together:
├── HOST / SERVICE CHECK
├── LOG / CONFIG CHECK
└── EXTERNAL DNS / HTTP CHECK
↓
SYNCHRONIZE REQUIRED RESULTS
↓
SYNTHESIS
Page 35's rule returns:
Parallel work removes some sequential waiting. Dependencies put waiting back wherever later work requires unfinished results.
Plans Need Preconditions
A step may make sense only if some condition is true.
| Proposed Step | Precondition |
|---|---|
| Read Apache log | Correct host and log source identified; read permission available. |
| Run config test | Approved non-destructive execution capability available. |
| Restart service | Change/execute authority exists and mission permits repair. |
| Produce final diagnosis | Sufficient evidence gathered or uncertainty explicitly preserved. |
Checking preconditions prevents a plan from becoming a blind script.
Then the World Disagrees
Suppose the initial plan expects the service to be stopped:
Observation: service is running normally.
New evidence: external HTTP request still fails.
The old path—“inspect why service failed”—no longer matches observed state.
Replanning begins when evidence makes the current plan less useful than a revised one.
Replanning Is Not Failure
Changing the plan can be exactly the correct behavior.
A brittle system treats its original sequence as an obligation. A responsive system treats the plan as a hypothesis about useful future work.
New observation: service healthy.
Revised path: inspect listener, firewall, reverse proxy, routing or external path.
The mission stayed the same. The route changed.
Evidence Should Beat the Plan
If the evidence contradicts an assumption, the assumption should be reconsidered. Otherwise the plan can become a source of confirmation bias—both for humans and AI systems.
The plan serves the mission. The mission does not serve the plan.
Plans Can Contain Branches
├── RUNNING → CHECK NETWORK / APPLICATION PATH
└── FAILED → READ LOGS / TEST CONFIGURATION
This is conditional planning: the next action depends on the observed result.
The model or orchestrator need not enumerate every possible branch in advance. Some branches can be generated when their conditions arise.
Plans Can Be Wrong Before the First Step
A fluent plan may contain:
Impossible Steps
Calls a tool or resource that does not exist.
Unauthorized Steps
Assumes permissions the agent does not have.
Missing Dependencies
Uses information before it has been obtained.
Unnecessary Work
Performs expensive tasks that do not advance the goal.
Plans therefore benefit from validation before execution.
Planning and R/W/X
Page 33's control boundary still applies. A plan may contain a proposed operation that is not authorized.
A denied step should cause state update and possibly replanning—not repeated attempts to evade the boundary.
Planning and Failure Recovery
Page 36 showed several recovery choices. Planning decides how they fit into the mission.
Recovery is therefore often a local replanning problem.
Cost Is Part of Planning
Several routes may reach the same goal.
| Route | Possible Tradeoff |
|---|---|
| One agent, sequential | Simple, but potentially slower. |
| Several agents in parallel | Faster in some cases, but more inference and coordination cost. |
| Expensive authoritative tool | Higher cost, potentially stronger evidence. |
| Cheap preliminary check | Fast screening, but may require later verification. |
Planning can therefore optimize for more than correctness: time, money, token use, risk, energy, resource contention and human attention can matter.
Plans Need Stop Conditions
A plan without completion criteria can keep expanding.
• goal is satisfied and verified
• sufficient evidence supports the requested report
• remaining uncertainty is explicitly documented
• required permission is unavailable
• cost/time/attempt limit is reached
• human decision is required
“Do more work” is not always progress.
Multi-Agent Planning
In a multi-agent system, planning can itself be distributed.
Central Planner
One component decomposes the mission and assigns tasks.
Supervisor Agent
A coordinating agent plans, delegates and revises assignments.
Local Planning
Each agent receives a subgoal and determines its own steps.
Hybrid
Global milestones are centralized while local tactics remain flexible.
Replanning Changes the Dependency Graph
Suppose Agent C's external test reveals that DNS is wrong. Several previously planned tasks may become irrelevant, while a new verification branch appears.
For WITNESS, preserving only the final plan would erase why earlier work was abandoned.
Plan Versioning
A useful evidence record can treat plans as versions:
Observation E17: service running
Plan P2: external-path investigation
Observation E24: DNS target incorrect
Plan P3: verify DNS configuration and impact
Now we can reconstruct not only what happened, but why the intended future changed.
Planning Is Not Hidden Proof of Reasoning
If a model outputs a beautiful plan, that plan is observable generated content. It can help us understand the system's proposed strategy, but it is not automatically a faithful transcript of every internal computation that produced it.
HAAW keeps the distinction:
INTERNAL CAUSAL MECHANISM = INTERPRETABILITY QUESTION
Human Replanning
A human can alter the mission at any time:
Human: “Do not access production. Use the staging configuration and report what remains unknown.”
The correct system response is not to defend its original plan. It is to update constraints and replan.
WITNESS: Record Intent Separately From Event
Planning creates a new evidence category: intended future action.
WITNESS should not collapse these.
A plan tells us what the system intended to try. The event record tells us what actually happened.
The Familiar Human Parallel
This is not alien logic. Craig's old exam strategy had the same broad structure:
The plan organized resources, but the next decision could change as the test unfolded.
Likewise, a sysadmin does not keep debugging the network after discovering a syntax error merely because “network test” was originally step six.
The Boundary
A goal describes the desired outcome.
A plan proposes a route toward that outcome.
A task is a unit of proposed or assigned work.
An event is something that actually occurred.
An observation can confirm or contradict assumptions in the plan.
Replanning changes the proposed route when state, evidence, constraints or capabilities change.
The plan may guide action, but authorization and verification remain separate boundaries.
The plan serves the mission. The evidence gets a vote.
HAAW Checkpoint
Goal: The desired outcome or completion condition.
Plan: A proposed route from current state toward a goal.
Subgoal: An intermediate objective supporting the larger goal.
Task: A unit of work assigned or proposed within the plan.
Precondition: A condition that should hold before a task is attempted.
Dependency: A relationship requiring another result or event before work can correctly proceed.
Branch: An alternate path selected according to observed conditions.
Replanning: Revising future work in response to new evidence, failure, changed constraints or changed state.
Plan Version: A recorded state of the proposed route at a particular point in the mission.
Stop Condition: A rule defining when work should finish or escalate.
Plan vs Event: A plan describes intended future work; an event records something that actually occurred.
Central lesson: A useful agent does not merely follow a plan—it tests the plan against the world and changes course when the evidence requires it.
Goals, Constraints and Mission Success — Who Decides What “Done” Means?