Planning and Task Decomposition

Planning can make a long task understandable, expose dependencies, and create useful checkpoints. It can also add ceremony, lock a system into an early misunderstanding, or produce a persuasive sequence whose steps are impossible. Not every multi-step task needs a separate planner.

Thesis

A generated plan is a versioned working hypothesis about how to reach a goal. The runtime must validate its constraints, execute only eligible next steps, and revise it from observed state.

The plan does not grant permission, prove feasibility, reserve resources, or establish that a task is complete. Those responsibilities remain with tools, state, policy, the control loop, and verification.

When explicit planning helps

Use an explicit plan when it provides a coordination or correctness benefit:

• the task has dependencies that affect order;
• several artifacts or actors must converge;
• expensive or consequential actions benefit from preview;
• the work must pause and resume;
• parallel tasks need boundaries and a join condition;
• progress and remaining obligations must be visible; or
• evidence suggests the initial route will need deliberate revision.

For a short, reversible task with immediate feedback, choosing one action at a time may be simpler. A separate planner call consumes context and latency and may speculate before the environment is observed.

Plan-and-Solve showed that explicit decomposition improved results over its prompting baselines on evaluated reasoning datasets (Wang et al., 2023). Conversely, controlled planning research found poor autonomous executability on the tested classical-planning domains and better prospects when LLM proposals were checked by external planners or verifiers (Valmeekam et al., 2023). Neither result dictates all modern agent design. Together they support a practical rule: decomposition can help, but validity must come from the task environment and appropriate checks.

A plan is more than a list of prose steps

Represent enough structure to execute and revise:

Field	Purpose
Goal and success evidence	Defines what the plan is intended to achieve
Assumptions and constraints	Exposes facts on which feasibility depends
Step ID and objective	Gives each unit stable identity and bounded purpose
Dependencies	Defines order and parallel eligibility
Inputs and expected outputs	Establishes handoff contracts
Owner and authority	Names who may act and within which scope
Preconditions	States what must be true before execution
Verification	Defines how the step’s outcome is checked
Failure and replan triggers	Defines when the route is no longer credible
Status and evidence	Links the plan to actual run state

Keep this representation outside the model transcript. The model may propose changes, but the harness applies legal transitions and records versions.

Choose the right decomposition boundary

A good task unit has a coherent outcome that another component can consume and verify. It is not simply “think about X.” Useful boundaries often align with:

• one artifact or state change;
• one evidence question;
• one responsibility or domain;
• one permission boundary;
• one independently executable branch; or
• one verification checkpoint.

Over-decomposition creates handoffs, duplicated context, and coordination cost. Under-decomposition creates opaque tasks that cannot be scheduled, bounded, or verified. Granularity is an evaluation variable: measure whether decomposition improves outcome and recovery enough to justify overhead.

Plan from current state, then act one boundary at a time

An execution cycle can be:

1. load the goal, authoritative state, constraints, and current plan version;
2. identify eligible next steps whose dependencies and preconditions are satisfied;
3. select one step or bounded parallel set;
4. validate action authority and resource limits;
5. execute and verify outcomes;
6. update state and plan status from evidence; and
7. continue, revise, wait, escalate, or stop.

This keeps planning subordinate to the control loop. The plan suggests future transitions; it does not pre-authorize them. A change in permissions, inventory, user intent, or external state can invalidate a step even when the plan was previously approved.

Replanning needs a trigger

Replanning after every step can make the system unstable; never replanning makes it brittle. Define triggers such as:

• a precondition is false or a dependency changed;
• the expected output cannot be verified;
• a step reveals a new material constraint;
• the user changes the goal or scope;
• resource consumption exceeds the estimate;
• repeated attempts produce no task-relevant progress;
• a risk or approval boundary changes; or
• a more direct route becomes available.

Preserve why the old plan was superseded and which completed effects remain. Do not regenerate the whole plan merely to make it look coherent; uncontrolled rewriting can lose obligations and duplicate actions.

Use deterministic planning where constraints are formal

Language models are useful for interpreting ambiguous goals, proposing decompositions, and adapting to semantic feedback. They should not replace a sound solver where the problem already has formal constraints and correctness matters—for example scheduling, graph reachability, access policy, resource allocation, or transaction invariants.

A hybrid design can let the model translate intent into candidate constraints, then use a planner, optimizer, database, compiler, or rule engine to check and produce valid operations. The model can explain the result, but the formal component owns the guarantee within its assumptions.

Parallelism is a dependency decision

Run steps in parallel only when their inputs are stable enough, effects do not conflict, budgets allow it, and the join condition is defined. Record state versions and ownership. Two tasks that both edit the same artifact, consume the same quota, or make dependent external changes are not independent merely because their descriptions differ.

At the join, validate each result against its contract, resolve conflicts, and check global success conditions. “All workers returned” is not the same as “all required outputs are valid.” Multi-Agent Systems will cover coordination when separate agent loops are justified; ordinary parallel jobs do not automatically require multiple agents.

Plans and people

Plans can make consequential work reviewable if they show concrete effects, dependencies, uncertainty, and approval points. Approval of a high-level plan should not automatically approve every later action when arguments or consequences were unknown. Bind approval to scope, thresholds, time, and change rules.

When a person intervenes, capture whether they corrected the goal, changed a constraint, approved a step, took ownership, or merely provided information. Each has different implications for the remaining plan.

Failure modes

Plan as prophecy

The system follows an early sequence after the environment changes. Validate the next step against current state.

Plan as authorization

Approval of prose is treated as permission for unspecified effects. Validate and, where required, approve concrete actions.

Decorative planning

A plan is generated for display but execution does not reference step IDs, dependencies, or checks. Either connect it to state or remove the ceremony.

Endless replanning

The system rewrites tasks instead of acting or gathering new evidence. Require a trigger and bound revisions.

False parallelism

Workers share mutable inputs or effects and silently overwrite one another. Define ownership, versions, and join semantics.

Tiny task explosion

Every thought becomes a task. Coordination consumes more effort than execution. Decompose around verifiable outcomes and real boundaries.

Completion by checked boxes

Every planned step is marked done, but the original success condition is unmet. Verify the goal independently of plan status.

Fieldbook guidance

Use the smallest planning contract that makes dependencies and verification explicit:

goal, scope, and success evidence
assumptions, constraints, and authoritative state version
steps with IDs, outcomes, dependencies, owners, and limits
preconditions, authority, and verification per step
parallel groups and join conditions
replan triggers and maximum revisions
completed effects that survive a plan change
approval and handoff boundaries

Checklist

• Does explicit planning provide a measured benefit for this task class?
• Is the plan stored as versioned working state rather than hidden in prose?
• Does each step have a bounded outcome, dependencies, inputs, owner, and verification?
• Are authority and current preconditions checked again before execution?
• Are plan completion and goal completion evaluated separately?
• Are replan triggers and revision limits explicit?
• Do plan updates preserve completed effects, unresolved obligations, and reasons for change?
• Are formal constraints delegated to sound deterministic mechanisms where appropriate?
• Is parallel work genuinely independent, versioned, and joined through result contracts?
• Can a person review concrete consequences rather than an abstract sequence alone?

References and how they are used

• Wang et al., “Plan-and-Solve Prompting” — peer-reviewed evidence that explicit decomposition improved the evaluated reasoning tasks; not generalized to all agent workflows.
• Valmeekam et al., “On the Planning Abilities of Large Language Models: A Critical Investigation” — primary research used to distinguish plausible generated plans from executable plans and to support external planners and verifiers.
• Yao et al., “ReAct” — primary research supporting interleaving actions and observations rather than committing to a complete open-loop plan.
• NIST AI 600-1, Generative Artificial Intelligence Profile — risk-management profile supporting documented assumptions, human oversight, testing, and change management around GAI systems.