Planning is the process of choosing and ordering actions so a system can move from a current state toward a goal while respecting constraints. In Super Intelligence, a written plan is only one representation of that process. A dependable planner must track state, preconditions, consequences, resources, uncertainty, permissions and feedback from the environment.
A model can produce an impressive sequence of steps that is impossible to execute. It can also revise a plan after new evidence arrives. The difference between those two outcomes is not style; it is whether the plan is grounded in the actual state and checked against the rules that govern action.
This article explains planning in SI: goals, states, actions, preconditions, effects, constraints, partial-order plans, schedules, replanning, hierarchical planning, tool use, model predictive control, plan validation, uncertainty and execution monitoring. It also distinguishes planning from problem decomposition, search and actual action.
Research such as Do As I Can, Not As I Say: Grounding Language in Robotic Affordances showed one way to combine language-model knowledge with grounded action feasibility, while ReAct explored interleaving reasoning and actions. The lesson is general: a useful plan depends on what actions are actually available in the environment.
Previous: 035 — Problem Decomposition. Here the subproblems become a route through states and actions.
The Hidden Transition: A To-Do List Is Not Yet a Plan
Suppose a model writes: “Book venue, invite parents, prepare materials, assign tutors, publish schedule.” The sequence sounds reasonable, but it ignores dependencies. You cannot publish a schedule before confirming venue and tutor availability. Invitations may need the final date. Materials depend on enrolment numbers.
A real plan makes these relationships explicit. It knows what must be true before each action, what changes after the action, and what remains unresolved.
State
State is the information that describes the planning environment at a particular moment. For an event, state may include date, room bookings, staff availability, enrolment count and publication status.
Planning fails when the state representation omits a fact that affects feasibility. A room that is “probably free” should not be treated as booked.
Goal
A goal describes the desired end condition. “Organise the event” is vague. “Event date confirmed, two rooms booked, four tutors assigned, parent notice published and registration open by Friday” is inspectable.
Goals should distinguish required outcomes from nice-to-have preferences.
Actions
Actions are operations that can change state. Book room, assign tutor, send invitation, create draft, publish page and cancel booking are different actions.
A language model can propose actions, but the available action set comes from the environment and tools.
Preconditions
A precondition is something that must be true before an action is valid. Publishing a parent notice may require an approved date, fee and venue.
Checking preconditions prevents the planner from acting on a sequence that is linguistically plausible but operationally impossible.
Effects
An action changes state. Booking Room 3 changes availability. Sending an invitation changes communication status. Paying a deposit changes budget and cancellation conditions.
A planner should update state from observed tool results rather than assume an intended effect occurred.
Hard Constraints
Hard constraints cannot be violated: one tutor cannot teach two rooms simultaneously; a room cannot exceed capacity; a publication must not precede required approval.
These constraints are excellent candidates for deterministic validation or a solver.
Soft Constraints
Soft constraints express preferences: minimise travel, keep the same tutor, prefer the larger room, avoid late evening.
A plan can trade them off when no solution satisfies all preferences. The trade-off policy should be explicit.
A Worked Planning Example: Three Tutorials, Two Rooms
Goal: schedule three 90-minute tutorials between 4 PM and 8 PM using Rooms A and B. Tutor T1 teaches Math and is available 4–8. Tutor T2 teaches Science and is available 5–8. Math must happen before Science because one student attends both. English uses T1 and can happen any time.
The planner first represents durations, teacher constraints, room capacity and ordering dependency. It can then search candidate schedules.
One feasible plan: Math 4–5:30 in A with T1; Science 5:30–7 in B with T2; English 5:30–7 in A with T1. The shared student attends Math then Science; T1 is not double-booked; rooms do not conflict.
The plan is useful because its feasibility can be checked. A prose plan that says “run all three after school” is not enough.
Sequential Planning
In sequential planning, actions occur one after another. The next action sees the state produced by the previous one.
This is appropriate when actions depend strongly on prior results, such as database migrations or multi-step approvals.
Partial-Order Planning
Some actions need ordering; others do not. Partial-order planning specifies only the dependencies that matter.
Prepare lesson materials and draft parent copy can happen in parallel after the event date is fixed. There is no need to force an arbitrary order between them.
This preserves flexibility and enables parallel execution.
Temporal Planning
Actions take time. A room booking spans an interval; travel consumes minutes; a file upload can time out. Temporal planning reasons about durations and overlaps.
A plan can be logically ordered yet impossible under the deadline because actions take too long.
Resource-Constrained Planning
Rooms, staff, machines, money and API quotas are resources. Actions consume or reserve them.
A planner that ignores resource capacity can produce a sequence where every step is individually legal but collectively impossible.
Planning Versus Scheduling
Scheduling assigns activities to time and resources. Planning determines which actions should happen and in what dependency structure.
Many real tasks combine both: choose the workflow, then schedule its actions.
Planning Versus Problem Decomposition
Decomposition asks what subproblems exist. Planning asks how to move through states and actions to complete them.
A task graph can become the skeleton of a plan, but the planner adds preconditions, effects, resources and execution order.
Planning Versus Search
Search is a method for exploring possible plans. Planning defines the state/action problem; search is one way to find a route through it.
Article 037 will examine search algorithms more deeply.
Planning Versus Execution
A plan is a proposal. Execution changes the world.
The system should not report an action as complete until the tool or environment confirms it. This distinction is central to agent reliability.
Classical Planning Representation
Classical planners often represent actions with preconditions and effects. If preconditions hold, the action can transition the state.
This formal structure makes plan validation and search possible without relying on natural-language intuition for every step.
PDDL Intuition
Planning Domain Definition Language, or PDDL, is one family of formal representations for states, actions, predicates and goals.
An SI system can translate a natural-language problem into a formal planning representation, use a planner, then translate the resulting plan back into human language.
The translation is a critical boundary that must be checked.
Hierarchical Task Planning
High-level tasks can be expanded into lower-level methods. “Prepare lesson” becomes select objectives, retrieve material, draft examples, create practice, verify answers and save draft.
Hierarchical planning combines decomposition and planning into reusable task methods.
Reusable Plans
Routine workflows can store plan templates. A new event uses the same skeleton but substitutes dates, rooms and people.
Templates reduce inference cost and improve consistency while preserving room for model-based adaptation when conditions differ.
Plan Libraries
An agent can retrieve previously successful plans for similar tasks and adapt them.
The stored plan should include the conditions under which it succeeded. Copying an old plan without checking new constraints creates hidden drift.
Planning Under Uncertainty
Real environments are uncertain. A supplier may be late, a room may become unavailable, a user may reject an option.
A robust plan includes branches or contingencies rather than pretending one future is guaranteed.
Conditional Plans
If Room A is approved, use Schedule A. If not, switch to Room B and reduce capacity. The plan explicitly represents alternative futures.
Conditional plans are stronger than discovering the contingency only after failure.
Contingency Planning
High-risk workflows identify likely failure modes and prepare recovery actions in advance.
A software deployment plan includes rollback. An event plan includes backup room and weather alternative. An agent plan includes tool failure handling.
Replanning
When observed state differs from expected state, the system should revise the plan.
Replanning is not failure by itself. It is the normal response to a changing environment.
Worked Replanning Example
The planner selected Friday 7:30 PM because the slot was free. Before execution another user books it.
The scheduling tool rejects the move. The planner refreshes availability, proposes 8:00 PM or Saturday, and returns to the approval boundary.
It does not pretend the original plan completed.
Execution Monitoring
After each consequential action, compare observed state with expected effects.
If “create file” should produce document D123 but no file appears, the plan is not ready to advance to “send document”.
Monitoring keeps plan state grounded in reality.
Plan Repair
A full replanning pass can be expensive. Sometimes only one local section needs repair.
If a tutor becomes unavailable, preserve the venue, materials and registration work; repair the staffing branch.
This mirrors local failure repair in problem decomposition.
Model Predictive Control Intuition
Model predictive control repeatedly plans over a future horizon, executes only the near-term action, observes the new state and replans.
This pattern is useful when the world is dynamic. It avoids committing too far into an uncertain future.
Rolling-Horizon Planning
Long projects can plan the next week in detail and later weeks more coarsely. As time approaches, the plan is refined with newer information.
This reduces wasted effort on distant assumptions that may change.
World Models
A planner needs some model of how actions affect the world. This can be explicit rules, a simulator, learned dynamics or a combination.
If the world model is wrong, a perfectly optimised plan can fail in reality.
Simulation Before Action
A system can run candidate plans through a simulator to estimate outcomes and constraint violations.
Simulation is evidence about the modelled environment, not proof of real-world success. Execution monitoring still matters.
Affordances
An affordance represents whether an action is feasible in the current environment. The SayCan work combined language-model scores with value functions representing whether a robot could execute candidate skills.
The general lesson is powerful: semantic plausibility and physical feasibility should both influence planning.
Tool Availability as Affordance
A model may plan “send email”, but if no email tool is connected, that action is not available.
The planner should build from the actual tool registry and permissions rather than imaginary capabilities.
Permissions as Planning Constraints
An action can be technically available but unauthorised. “Delete records” may exist in the system but remain outside the user’s approved task.
Planning must include authority, not only capability.
Human Approval Nodes
A plan can explicitly include approval: draft proposal → human review → publish.
This makes the human decision part of the executable workflow rather than an afterthought in prose.
Plan Validation
Before execution, test the plan against hard constraints. Does every action have satisfied preconditions? Are resources available? Are permissions valid? Does the goal follow if effects occur as expected?
Validation can reject an impossible plan before it changes external state.
Static Validation Versus Dynamic Validation
Static validation checks the plan using the current snapshot. Dynamic validation repeats checks immediately before action because state may have changed.
Consequential operations need both when race conditions are possible.
Plan Optimality
Many feasible plans exist. Optimisation chooses among them using cost, time, risk or preference.
“Optimal” is meaningless without an objective function. Fastest, cheapest and safest plans can differ.
Multi-Objective Planning
Real workflows balance several objectives. A tuition schedule may minimise tutor idle time while preserving student preferences and avoiding room conflicts.
The planner can present a Pareto frontier of trade-offs rather than collapse everything into one unexplained score.
Heuristics
A heuristic estimates which state is closer to the goal, guiding search toward promising plans.
Language models can supply heuristic judgments, but hard constraints should remain independently checked.
Planning With Search
From the current state, enumerate possible actions, predict next states, score them and expand promising branches.
The branching factor can grow exponentially, so heuristics and pruning are essential.
Planning With Language Models
A language model can propose high-level steps using learned world knowledge. This is useful when formal action models are incomplete.
The weakness is that the model can invent infeasible actions or skip constraints. Hybrid planning grounds proposals in tools and state.
ReAct-Style Interleaving
ReAct interleaves reasoning traces with actions and observations. The model can decide to search, inspect a result, then continue reasoning from the new observation.
The architecture reduces the gap between planning and execution because each action updates the context.
Plans as Programs
A structured plan can resemble a program: variables, conditions, loops, function calls and termination criteria.
This representation makes the plan executable and testable. It also allows ordinary software to enforce structure around model decisions.
Workflow Plans
A workflow engine can encode stable business processes while the model makes decisions inside selected nodes.
This hybrid limits autonomy to the parts that benefit from flexible reasoning.
Plans and Memory
Long plans need state across steps: completed actions, failed attempts, user decisions and tool results.
Memory should distinguish planned actions from observed outcomes. Otherwise the agent may remember an intention as if it happened.
Plans and Context Windows
A long plan can exceed the model’s useful context. Structured state summaries keep essential constraints visible.
The system can store full logs externally and supply only current state, goal and relevant history to the model.
Plan Drift
As an agent executes many steps, it can gradually shift from the original goal. Local actions still look reasonable while the overall task changes.
Periodic goal checks and immutable task constraints reduce drift.
Scope Creep
A user asks for a draft event plan. The agent begins booking vendors because that seems helpful.
The plan exceeded authority. Capability should not create new task scope.
Planning Loops
An agent can get stuck alternating between two actions or repeatedly gathering the same information.
Loop detection can hash state, count repeated tool calls or enforce progress metrics.
Dead Ends
A branch reaches a state from which the goal is impossible. Search should backtrack rather than continue decorating the dead-end plan.
Hard-constraint checking detects dead ends early.
Irreversible Actions
Some actions cannot be fully undone: sending a message, publishing private information, making a payment.
Plans should delay irreversible actions until prerequisite checks and approvals are complete.
Reversible Actions
Drafting, simulation and sandbox testing are safer early steps. A good plan uses reversible preparation to reduce uncertainty before committing.
Plan Provenance
Record which evidence justified major plan choices. If a hotel was selected because a source reported availability, preserve the source and timestamp.
When the plan later fails, provenance distinguishes stale evidence from bad reasoning.
Planning With Fresh Data
A plan using prices, schedules or availability should retrieve current state close to execution.
Pretrained knowledge can explain the domain but cannot guarantee current operational facts.
Planning With Databases
Databases provide authoritative state and transactions. The planner reads current state, proposes changes and uses narrow operations to commit them.
The database remains the source of truth after execution.
Planning With Search
Web or document search supplies external knowledge. The planner should not let untrusted retrieved text grant new authority.
Search informs plans; permissions govern actions.
Planning With Calculators and Solvers
Exact constraints and arithmetic can be delegated to deterministic tools.
The planner translates the human goal into a formal problem, receives the solution and explains it.
A Planning Failure Map
Level 1: vague goal. Level 2: incomplete state. Level 3: missing hard constraint. Level 4: imaginary action. Level 5: unsatisfied precondition. Level 6: wrong effect model. Level 7: resource conflict. Level 8: stale state. Level 9: plan drift. Level 10: execution differs from plan but monitoring misses it.
This eduKateSG map isolates planning failures from general model errors.
Worked Diagnosis: Beautiful Plan, Impossible Room
The model schedules 40 people in a room with capacity 30.
The plan violated a hard resource constraint. Add capacity to state and use deterministic validation.
Worked Diagnosis: Correct Plan, Stale Availability
The plan chooses a free slot, but another user books it before execution.
Revalidate state at the transaction boundary and replan after the conflict.
Worked Diagnosis: Tool Does Not Exist
The plan includes “send SMS” but the application has only email.
Build the plan from actual affordances or ask the user whether email is acceptable.
Worked Diagnosis: Agent Keeps Optimising After Approval
The user approved Schedule A, but the agent continues modifying it to reduce travel.
Approval should freeze the approved object or require renewed approval for material changes.
A Practical Planning Worksheet
State the goal. List current state. List hard and soft constraints. List available actions and permissions. Define preconditions and effects. Generate candidate plans. Validate feasibility. Compare trade-offs. Mark approval gates. Execute one step. Observe state. Replan when necessary. Stop when the goal is verified.
This worksheet turns planning from persuasive prose into an inspectable control loop.
Independent Exercise 1: State
A planner wants to move a lesson but does not know the current booking ID. What should happen first?
Answer
Resolve the current state from the scheduling system before proposing or executing a change.
Independent Exercise 2: Preconditions
Publication requires approved fee and venue. Fee is approved; venue is still pending. Can the publish action run?
Answer
No. A required precondition is false.
Independent Exercise 3: Replanning
A room becomes unavailable after the schedule was approved but before the event. What should the system do?
Answer
Update state, preserve unaffected work and replan the room-dependent portion, returning material changes for appropriate approval.
Independent Exercise 4: Soft Constraint
No feasible plan keeps the preferred tutor, but another tutor can satisfy every hard requirement. What should happen?
Answer
Present the feasible alternative and the preference trade-off. Do not violate hard constraints to preserve a soft preference.
Independent Exercise 5: Execution
The tool call to book a room times out. Can the planner assume the room is unbooked?
Answer
No. The outcome is uncertain. Check booking state or use idempotency support before retrying.
Plan Representations: Prose, Tables, Graphs and Formal State
A plan can be represented in several forms. Prose is easy for humans to read but can hide dependencies. Tables make responsibilities and timing visible. Graphs expose dependencies. Formal state/action representations support automated validation and search.
A mature SI application can move between representations: user goal in natural language → structured task graph → executable plan → human-readable summary.
Each translation is a possible failure point and should preserve identifiers, constraints and provenance.
Milestones Versus Actions
A milestone is a state that should become true, such as “venue confirmed”. An action is something performed to reach that state, such as “submit venue booking request”.
Confusing them causes plans to skip the operational work between intention and result. “Marketing completed” is a milestone label, not an executable action.
Plan Preconditions as Tests
Every consequential action can expose its preconditions as machine-checkable tests. Publish event page: date approved? venue approved? fee approved? draft current? user authorised?
If one test fails, the action remains blocked and the plan can route to the missing dependency.
Effects Should Be Observed, Not Assumed
An action has intended effects and observed effects. The intended effect of “book Room A” is status = booked. The observed effect comes from the booking service response or read-back.
Execution monitoring compares them. If they differ, the planner updates state from observation rather than continuing with the fiction that the plan succeeded.
Plans Need Negative Effects Too
Actions can remove capabilities or resources. Booking a room makes that slot unavailable to other activities. Spending budget reduces remaining funds.
Ignoring negative effects creates plans where the same resource is reused impossibly.
Durative Actions
Some actions occupy time while running. A 90-minute lesson consumes tutor and room resources across an interval.
Temporal planners reason about start time, duration and end time rather than treating actions as instantaneous labels.
Concurrent Actions
Actions can overlap when they do not compete for resources or violate constraints. Drafting materials and checking catering can proceed simultaneously.
Parallel execution shortens completion time, but only when concurrency is safe.
Mutex Constraints
Two actions are mutually exclusive when they cannot occur together. The same person cannot supervise two rooms at once; one file lock may prevent two conflicting writes.
Explicit mutex rules help a planner reject impossible concurrency before execution.
Resource Calendars
Human and physical resources have availability windows. A planner can query calendars instead of assuming continuous availability.
The calendar should be checked again near execution because availability changes.
Cumulative Resources
Some resources can be shared up to a capacity. A room with 30 seats can host several groups only if total occupancy stays within 30.
This differs from exclusive resources such as one tutor’s time slot. Planning systems need the correct resource model.
Consumable Resources
Budget, fuel, inventory and API quotas decrease when used. A plan that spends the same budget twice is invalid even if actions occur at different times.
Consumable-resource tracking turns planning into accounting as well as sequencing.
Renewable Resources
Rooms and staff become available again after use. These are renewable resources.
Temporal scheduling can reuse them after the previous action ends, provided transition time is included where necessary.
Travel and Setup Time
Real plans often fail because transition costs are omitted. A tutor needs time to move rooms; equipment needs setup; software deployment needs propagation.
Durations should include relevant setup and teardown, not only the visible task.
Deadlines
A plan can be logically feasible but late. Deadlines convert time into a hard constraint.
Backwards planning from a deadline can reveal the latest start time for each dependency and identify the critical path.
Slack
Slack is the time flexibility around an action without delaying the final goal. Low-slack tasks deserve attention because small delays can move the whole schedule.
A planner can prioritise low-slack nodes during execution monitoring.
Critical Path Method
For projects with known durations and dependencies, the critical path is the longest dependency chain that determines project completion time.
Shortening non-critical work may not change the finish date. Planning intelligence improves when it identifies the true bottleneck.
Uncertain Durations
Many durations are estimates. A plan can represent ranges or probability distributions rather than one exact number.
Buffers and contingency branches protect deadlines when uncertain actions overrun.
Robust Planning
A robust plan remains feasible across a range of plausible disturbances. It may sacrifice the theoretical optimum for resilience.
For example, leaving ten minutes between room changes can reduce utilisation slightly while making the schedule more tolerant of delays.
Scenario Planning
When uncertainty is structural, generate plans for several scenarios: high enrolment, expected enrolment, low enrolment.
Identify actions that are good across scenarios and decisions that should wait for more information.
Decision Points
A conditional plan contains explicit decision nodes: if registrations exceed 30 by Friday, open Room B; otherwise keep one room.
Decision points should specify the evidence and threshold that choose the branch.
Deferred Commitment
Do not decide early when waiting has information value and does not create unacceptable risk.
A planner can reserve options, gather evidence and commit later. This is especially useful under uncertainty.
Option Value
Keeping two suppliers available until attendance is known can have value even if one is slightly more expensive.
Planning should consider flexibility, not only immediate cost.
Risk Budgets
A plan can allocate acceptable risk by stage. Experimental analysis may tolerate uncertainty; financial transfer or public publication may require much stronger verification.
Risk budget is an organisational policy, not something the model invents from confidence.
Expected Utility
When outcomes are uncertain, a planner can compare actions using probability-weighted utility.
This requires explicit outcome values and probability estimates. Hidden value assumptions can make a mathematically correct calculation operationally wrong.
Worst-Case Planning
Some safety-critical tasks optimise against worst plausible outcomes rather than average expected utility.
This can produce conservative plans. The correct criterion depends on domain and consequence.
Constraint Satisfaction Versus Optimisation
First determine whether any plan satisfies hard constraints. Then optimise preferences among feasible plans.
Mixing the stages can allow a high-scoring infeasible plan to outrank a lower-scoring valid one.
Pareto Frontiers
When no single plan is best on every objective, present nondominated alternatives.
Plan A is cheaper but slower; Plan B is faster but costs more. Human decision-makers can choose based on priorities not encoded in one scalar score.
Planning and Negotiation
Multiple stakeholders may have conflicting preferences. A planner can surface conflicts and propose trade-offs but should not silently decide whose interests dominate.
Human governance remains part of planning when objectives are contested.
Multi-Agent Planning
Several agents can own different parts of a shared plan. Coordination needs shared state, resource locks and conflict resolution.
Without those mechanisms, agents can produce locally valid actions that collide globally.
Blackboard Architecture
One coordination pattern uses a shared structured workspace where agents post facts, proposed actions and status.
The blackboard reduces repeated messaging and gives all agents a common operational state.
Reservation Before Execution
Some resources can be tentatively reserved while the rest of the plan is validated.
Reservations need expiry rules so abandoned plans do not block resources indefinitely.
Two-Phase Commit Intuition
For multi-system operations, a prepare phase can verify that participants are ready before the final commit.
Distributed transactions are complex, but the planning lesson is useful: do not partially commit a coordinated action when the other required changes cannot complete.
Compensating Actions
When true rollback is impossible, workflows can define compensating actions. If a booking email was sent with a wrong time, the system can send a correction; it cannot erase the first email from recipients’ memory.
Compensation is not the same as reversibility and should be planned explicitly.
Plan Repair After Partial Execution
If half the plan has executed, replanning starts from the new real state, not from the original state.
Completed irreversible actions become constraints on the repair plan.
Recovery Points
A plan can define safe states where execution may pause without leaving dangerous partial work.
Software deployments use checkpoints and rollback points; agent workflows can use draft states and approval gates similarly.
Graceful Degradation
If the preferred tool is unavailable, a plan may fall back to a simpler safe mode.
Example: if document export fails, preserve the verified text draft and report that the file has not been created.
Plan Versioning
Plans change after new information or approval. Version every material revision so the executed object matches the reviewed object.
“Plan approved” should refer to a specific version, not an evolving document.
Change Control
Small cosmetic changes may not require new approval; changed dates, fees, recipients or actions often do.
The workflow should define material change rather than leaving it to ad hoc model judgment.
Plan Diff
A structured diff shows what changed between versions: one room changed, start time moved 30 minutes, two recipients added.
This reduces human review load and prevents approval fatigue.
Plans and Provenance
Every critical assumption should carry a source. “Room available” comes from booking system at time T. “Fee $80” comes from approved price list version V.
Provenance helps determine which part of a plan becomes stale when a source changes.
Freshness Windows
Different facts age at different rates. Building address may remain stable for years; seat availability can change in seconds.
Planning systems should assign refresh rules based on volatility and consequence.
Trigger-Based Replanning
Rather than continuously replan everything, watch for specific state changes: booking conflict, missed deadline, new approval, price change above threshold.
A trigger starts local replanning only when a material condition changes.
Event-Driven Planning
External events update state and wake the relevant workflow. This is more efficient than polling every resource constantly.
Events must be authenticated and deduplicated so one external change does not trigger repeated action.
Plans and Observability
Track plan version, current node, completed actions, blocked actions, unresolved assumptions, resource use and next decision.
This dashboard state is more useful than an opaque “agent working” indicator.
Plan Health Metrics
Useful metrics include completion rate, replanning frequency, constraint violations, time to recover, human intervention rate and cost per completed task.
A planner that finishes often but violates constraints is not healthy.
Calibration of Plan Confidence
If a system predicts “80% chance plan completes on time”, compare those estimates with observed completion frequencies.
Natural-language confidence without empirical calibration should not be treated as a probability.
Plan Quality Versus Plan Length
A twenty-step plan is not inherently better than a six-step plan. Extra steps create more dependencies and failure points.
Prefer the minimum structure that preserves necessary controls.
Plans for Easy Versus Hard Tasks
A simple rewrite may need no explicit plan. A multi-week deployment requires milestones, dependencies, rollback and monitoring.
Planning overhead should scale with task complexity and consequence.
Planning Under a Compute Budget
Test-time compute from Article 034 applies here. Generate one plan for easy tasks, several candidates for hard tasks, and use solvers when exact constraints dominate.
Stop once a validated feasible plan meets the objective rather than searching forever for marginal improvement.
Planning Completion Standard
A plan is complete before execution when the goal, current state, constraints, actions, dependencies, resources, approval gates, recovery routes and verification rules are explicit enough to test. The task itself is complete only when the required goal state is observed after execution.
That distinction protects users from one of the most common agent errors: reporting a well-written plan as though the world had already changed.
Independent Exercise 6: Critical Path
Three tasks take 2, 5 and 3 hours sequentially on one dependency chain; another independent task takes 8 hours. What determines the minimum finish time?
Answer
The sequential chain takes 10 hours, so it is longer than the independent 8-hour task and determines the minimum finish time, assuming they start together.
Independent Exercise 7: Deferred Commitment
Attendance is unknown and choosing a room today is not necessary. What may be better than immediately booking the largest expensive room?
Answer
Preserve options until attendance evidence improves, provided waiting does not risk losing every feasible room.
Independent Exercise 8: Plan Diff
An approved plan changes only font and spacing. Does it necessarily need full reapproval?
Answer
Not necessarily if the workflow defines those changes as non-material. Approval policy should distinguish cosmetic and consequential changes.
Independent Exercise 9: Compensating Action
A wrong email has already been sent. Can rollback erase the consequence?
Answer
No. A compensating correction can be sent, but the original message may already have been read or copied.
Independent Exercise 10: Freshness
A plan relies on a room-availability query from yesterday. Should the system execute a booking today without rechecking?
Answer
No. Availability is volatile and should be refreshed near the transaction boundary.
Frequently Asked Questions About Planning in SI
What is planning?
Choosing and ordering actions that move a system from current state toward a goal under constraints.
Is a generated checklist a plan?
It can be a plan representation, but a dependable operational plan also needs state, dependencies, feasibility and execution monitoring.
How is planning different from decomposition?
Decomposition identifies subproblems. Planning arranges actions and state transitions to complete them.
How is planning different from search?
Search is one method for exploring possible action sequences. Planning defines the goal, state, actions and constraints being searched.
Can an LLM plan by itself?
It can propose useful plans, but real applications should ground actions in actual tools, state, constraints and verification.
Why replan?
Because environments change and actions can fail. Replanning updates the route from the new observed state.
What is an affordance?
Whether an action is feasible or available in the current environment. A plan should prefer actions the system can actually execute.
What is the final completion test?
The goal state must be observed or verified, not merely described as achieved in the plan.
Planning Connects Reasoning to Controlled Action
Planning is where SI moves from solving a static problem to organising a sequence that can change the world. That makes state, permissions, resources and feedback as important as model intelligence.
A strong plan is executable, monitorable and repairable. It knows what must be true, what each action is expected to change, what to do when reality disagrees and when to return control to a person.
Continue through the How Super Intelligence Works hub. Previous: 035 — Problem Decomposition. Next: 037 — Search.
Final Planning Exercise: Turn a Proposal Into an Executable Route
Choose a harmless plan such as organising a study session. Write the current state, the goal state, available rooms, people, time windows and materials. For each proposed action, write its preconditions and expected effects. Then identify which facts are live state that must be rechecked near execution.
Create one disturbance: the room becomes unavailable, one participant cannot attend, or the start time changes. Do not rewrite the whole plan automatically. Identify which actions and dependencies are affected, preserve unaffected work and produce a repair from the new observed state.
Next add an authority boundary. Let the system draft an invitation but require explicit approval before sending. The plan must include the approval as a real node, not bury it in prose. If approval is withdrawn or the draft changes materially, execution must stop or return for review.
Finally, define completion in observable terms: room reservation confirmed, attendees recorded, materials ready and approved invitation sent. A plan is not complete because every future action has been written down. The task is complete only when the required state exists and the system can point to the evidence for it.
This exercise captures the practical difference between planning and storytelling. A story describes what should happen. An executable SI plan connects every step to state, feasibility, authority, evidence and recovery.
Planning Reality Check: The Environment Gets the Final Vote
Every SI plan remains provisional until the environment confirms its transitions. A model can predict that a room will be booked, a message will be sent, a file will be created or a database record will change. The authoritative state comes from the relevant service after execution. Planning therefore ends each consequential step with observation, not narration.
This distinction becomes more important as autonomy grows. A five-step plan with four verified actions and one unknown action is not “basically complete”. The unknown result may block every later dependency. The planner should preserve completed work, mark the uncertainty, resolve it through status checks or human input, and only then continue along a branch whose preconditions are actually true.
The same rule applies to long horizons. Plans for next week should contain more concrete commitments than plans for next year because current evidence weakens with distance. Good planning does not pretend uncertainty is a defect that can always be removed. It decides what must be fixed now, what can remain conditional and which future observation will trigger the next commitment.
A reader has mastered SI planning when they can distinguish goal from state, action from effect, preference from hard constraint, proposed route from executed route, simulation from observation and rollback from compensation. Those distinctions are what make an agent’s plan safe enough to become an operating workflow rather than an attractive paragraph.
Planning Floor Margin
A production planner should also expose the next blocked condition in plain language. “Waiting for venue approval” is operationally useful; “still thinking” is not. This small reporting discipline connects the internal state machine to the human operator and makes long plans interruptible, reviewable and recoverable. It also prevents the model from converting an unresolved dependency into a confident completion message simply because every planned sentence has already been generated.
The final planning floor also requires a visible escalation route when the model cannot establish a feasible next action. Returning a precise blocker is better than inventing progress.
Planning Floor Completion
The final operational test is interruption. A good plan can be paused at any meaningful boundary and still tell the next operator what has been completed, what remains pending, which resources are reserved, what evidence is current and what decision is required next. This makes planning durable across people, agents, failures and time rather than dependent on one uninterrupted model session.
When that state is explicit, planning becomes a controlled state-transition system. When it is absent, the plan remains prose. This is the floor required before the next mechanism—search—can safely explore alternative routes.