Agent Planning and Task Decomposition

Why planning decides reliability

Give a capable model a genuinely complex goal in a single instruction, book a five-city itinerary within budget, reconcile these two ledgers and file the exceptions, and watch what happens. It produces a fluent, plausible, and usually wrong answer, because it has tried to hold the entire problem in one forward pass and collapse it into one response. Real work does not decompose itself. The difference between a demo and a system that survives contact with production is almost never a better prompt; it is whether the agent turned the goal into a sequence of steps it could actually execute and check.

That act of turning a goal into steps is planning, and the act of breaking the goal into smaller pieces is decomposition. They are the connective tissue of the entire agentic stack. Tool calling gives an agent hands, but hands without a plan flail. An agent is, at bottom, a model looping toward a goal, and the quality of that loop, what it attempts next, in what order, and how it knows a step succeeded, is set by how it plans.

Planning matters for reliability specifically because it makes failure localizable. A monolithic attempt either works or does not, and when it does not you have no purchase on why. A planned, decomposed attempt fails at an identifiable step, which you can retry, reroute, or gate for human review without discarding the correct work around it. This is the throughline of everything below: planning is not about making the agent cleverer, it is about making its work observable, checkable, and recoverable one step at a time. Get that right and mediocre models become useful; get it wrong and the strongest model available still produces confident nonsense.

ReAct versus plan-and-execute

Two patterns dominate how agents structure their work, and they sit at opposite ends of a reactive-to-deliberate spectrum. ReAct interleaves reasoning and acting: the agent thinks a little, takes one action, observes the result, then thinks again with that result in hand. Nothing is decided far in advance; each step is chosen against the freshest state of the world. Plan-and-execute inverts the order. The agent first produces a complete plan, an ordered list of steps toward the goal, and only then executes them, optionally revising the plan if execution goes off the rails.

The trade-off is real and it cuts both ways. ReAct adapts gracefully when the environment is uncertain or surprises are common, because it never commits to a step it has not yet reached. But it is myopic: with no global view it can wander, repeat itself, or lose the thread on a long task. Plan-and-execute buys coherence and a legible artifact you can inspect before anything runs, which matters when actions have consequences, but it is brittle when reality diverges from the plan and can spend effort on a strategy that was wrong from step one.

In practice the useful systems are hybrids. A common and durable shape is to plan upfront for structure, then run each step in a small reactive loop that can observe and adjust, and trigger a replan only when execution drifts far enough from expectation to warrant it. Treat the two names as ends of a dial you set per task, not as rival frameworks where one must win.

Decomposition into subtasks

Whichever pattern drives the loop, its output is only as good as the pieces it produces, and here there is a discipline worth stating plainly: decompose a goal until each subtask is small enough to execute in a step or two and concrete enough that you can tell whether it succeeded. The second half is the one teams skip. A subtask you cannot verify is not a subtask, it is a wish, and a plan made of wishes fails exactly the way the monolithic attempt did, silently and all at once.

Verifiability is what converts decomposition from tidiness into reliability. When a step has a checkable postcondition, the invoice exists, the total matches, the file parses, a failure is caught at that step rather than propagated downstream dressed as success. That is what makes failure localizable: you know which node broke, you retry or reroute just that node, and the correct work around it survives. Decomposition also exposes structure the agent can exploit, independent branches that can run in parallel, and genuine dependencies that must run in order.

  GOAL: reconcile two ledgers, file exceptions
    |
    +-- 1. load ledger A            [check: rows > 0]
    +-- 2. load ledger B            [check: rows > 0]
    |        (1 and 2 independent -> parallel)
    +-- 3. match entries            [check: all matched
    |                                 or flagged]
    +-- 4. compute deltas           [check: sums tie]
    +-- 5. file exceptions          [check: ticket id
                                      returned]

Decomposition can go too far. Splitting a two-line task into eight subtasks buys nothing and, as the next sections show, costs real money and latency per step. The right grain is the coarsest one at which every piece is still independently verifiable. Below that grain you are adding failure points; above it you are back to hoping.

Reflection and self-critique

Reflection adds a loop where the agent reviews its own work and revises it: it produces a draft, critiques that draft against the goal or some criteria, and generates an improved version, sometimes several times over. When it helps, it helps a lot. On tasks with a clear standard the agent can check against, code that must compile and pass tests, output that must satisfy a schema, a claim that must be supported by a retrieved source, a critique-and-revise pass catches concrete, checkable defects the first attempt missed. The signal is external and verifiable, so the second look has something real to bite on.

The failure is subtler and more common than the literature admits. On tasks with no objective standard, or where the same model both produces and grades the work, reflection frequently just rephrases. The critique reads as thoughtful, the revision looks different, and quality is unchanged, because a model's self-assessment is not an independent measurement, it is another sample from the same distribution that produced the error. You pay for a full extra generation and get motion without improvement. Worse, an over-eager reflection loop can talk itself out of a correct answer, revising toward a confident mistake.

The practical rule follows directly. Add reflection where you have a cheap, objective verifier and a task hard enough that first attempts genuinely fail, and bound it hard, one or two passes with a stop condition, never an open loop. Everywhere else, treat it as a hypothesis to be tested against your evaluation suite, not a default. Reflection is a tool with a narrow, real sweet spot, not a free upgrade you sprinkle on every step.

Reasoning models plan better

There is a direct line between a model's reasoning ability and the quality of the plans it produces, and it is worth being precise about why. Planning is itself a reasoning task: deciding what the subgoals are, in what order they must run, which depend on which, and what could go wrong is exactly the kind of multi-step deliberation that reasoning models are trained to do. A model that spends more test-time compute working through a problem before committing, generating and weighing intermediate steps rather than answering in one pass, tends to produce plans that are more complete, better ordered, and less likely to omit a dependency or skip a verification step.

This reframes a design choice teams often get backwards. The instinct is to save the expensive reasoning model for the hard sub-steps and let a cheap model handle the plan. Frequently the opposite pays off. The plan is leverage: a flawed plan sends every downstream step, however well executed, toward the wrong goal, while a sound plan lets weaker, cheaper models execute individual subtasks reliably because each one is now small and well specified. Spending your compute budget on getting the decomposition right is often the highest-return allocation in the whole system.

Two cautions keep this honest. First, more reasoning has diminishing and eventually negative returns: past the point where a task's genuine difficulty is met, additional deliberation adds latency and cost without better plans, and can overthink a simple goal into an elaborate one. Second, a better plan is not a correct plan. Stronger reasoning raises the floor and narrows the error rate; it does not remove the need for verifiable subtasks and boundary checks. Use reasoning where the planning is genuinely hard, size the compute to the difficulty rather than maxing it by reflex, and keep the same verification discipline you would apply to any plan regardless of how the plan was produced.

The cost of every step

Every step in a plan is not free, and the accounting is unforgiving. Each step is at least one model call, which means tokens billed, latency incurred, and one more place the agent can go wrong. Because an agentic loop feeds prior context back in, the token cost of step N carries the accumulated history of steps one through N minus one, so a long plan does not cost linearly in steps, it costs faster than that. A plan with twice the steps can easily cost more than twice as much and take more than twice as long.

Latency compounds in a way worth understanding mechanically. Model inference is dominated by the sequential decode phase, one output token at a time, so the length of what each step generates, not just how many steps there are, drives wall-clock time, and the steps in a plan run in sequence unless you have explicitly made them parallel. Reasoning steps that emit long internal deliberation are the quiet latency sink here. Streaming can improve how responsive the agent feels, but it does not reduce the total time to a finished result.

The discipline that falls out of this is simple to state and easy to neglect under pressure to make an agent look thorough: keep the plan as short as the task genuinely allows. Decompose to the coarsest grain at which each step is still verifiable, and no finer. Collapse steps that do not need to be separate, run independent steps in parallel, and cap the loop so a wandering agent cannot rack up cost without converging. A short plan of reliable, checkable steps beats a long plan of clever ones on every axis a CTO cares about, cost, speed, and the odds it finishes at all.

The architect view

Planning and decomposition are where an agent stops being a chat interface and starts being a system, and like any system property they should be designed and evaluated rather than left to emerge from a prompt. The good news for an enterprise is that the required disciplines, decomposition, verification, dependency management, and cost control, are engineering practices your organization already understands. The work is applying them to a probabilistic component instead of a deterministic one.

Four commitments carry most of the weight, and they are worth putting in place before an agent reaches production rather than after an incident:

1. Match the pattern to the task. Use reactive interleaving for uncertain, exploratory, short work and upfront planning for structured, consequential, multi-step work, and reach for a hybrid, plan for structure, execute each step reactively, as the default for anything nontrivial.
2. Decompose into verifiable subtasks. Every step gets a checkable postcondition, at the coarsest grain that keeps it verifiable. A step you cannot check is a step you cannot trust, and it is where silent failure hides.
3. Cap the loop. Bound steps, retries, and reflection passes with explicit budgets and stop conditions, so no agent can spend unboundedly or spiral. Reflection specifically earns its place only where an external verifier grades it.
4. Evaluate planning quality directly. Treat the plan as a first-class output to measure, not a hidden intermediate, tracking where plans go wrong, which steps fail, and what each run costs against your evaluation suite.

The thread through all four is that reliability lives in structure, not in cleverness. A stronger reasoning model raises the floor, but the systems that hold up in production are the ones whose plans are short, whose subtasks are checkable, and whose loops are bounded. This is also where planning meets multi-agent systems, since handing subtasks to specialized agents is decomposition taken to the level of the agent itself, and the same rules apply, verifiable interfaces and bounded coordination. To watch these loops plan, execute, and self-correct against real tasks, the self-correcting agent in the Lab runs exactly this cycle end to end.