Multi-Step Planning

Plan upfront or decide as you go? The tradeoff is coherence against adaptability, and the practical answer is usually a shallow plan you revise.

An agent facing a multi-step task has two options: work out the whole sequence first, or decide each step as it arrives.

Both fail in characteristic ways, and knowing which failure you are looking at tells you which to adjust.

Plan-first

Generate an explicit plan, then execute it.

1. Search for the config file
2. Read it
3. Find the database section
4. Update the connection string
5. Validate the syntax

What it buys. Coherence — the steps fit together toward the goal. Inspectability, since a human can review the plan before anything runs. Bounded scope, because the plan implies a step count. And written reasoning is genuine computation, so planning improves the steps themselves.

Where it fails. Plans are written in ignorance. Step 3 assumed a database section that does not exist. Now the agent either abandons the plan — making it decorative — or follows it into failure. Rigid plan-following is a real observed failure mode: agents continuing to execute steps that stopped making sense three steps ago.

React-as-you-go

Decide each step from the current state, no plan at all. This is the plain agent loop.

What it buys. Full adaptability. Every decision uses everything learned so far, and surprises are handled naturally because nothing was committed.

Where it fails. Drift. Without a persistent objective, long runs wander — pursuing an interesting tangent, losing the original goal. Local decisions each look reasonable while the trajectory goes nowhere. Also prone to repetition, retrying variations of a failed approach with no memory that the approach was already tried.

What actually works

The productive middle: a shallow plan, revised as you learn.

Plan three to five steps rather than fifteen. Execute. Re-plan when a result contradicts an assumption.

Concretely, either give the agent an explicit update_plan tool, or re-plan on a fixed cadence — every few steps, restate the goal, what has been learned, and what remains. The plan becomes a working hypothesis rather than a contract.

Two supporting practices matter as much as the structure:

Keep the goal in front of it. Restate the objective every iteration, not just in the system prompt. Drift is largely a matter of the goal being buried under accumulated transcript.

Track what has been tried. An explicit list of attempted approaches and outcomes prevents the most common wasted iterations. This is also the cheapest defense against repetition loops.

Decomposition

For genuinely large tasks, sequencing steps is the wrong frame. Split into subtasks with their own contexts.

Each subtask gets a fresh, short transcript and returns a compact result. This directly attacks the quadratic context growth of long single loops, and it means a failure in one subtask does not corrupt the others.

The cost is coordination — subtasks lack each other’s context, so the boundaries have to be chosen so they do not need it. When that holds, decomposition is the only approach that scales to long work.

Why long horizons stay hard

Two arithmetic facts bound what is achievable.

Reliability compounds downward. 95% per step is about 60% over ten steps, 36% over twenty. Planning does not change the exponent.

Context grows quadratically. Each iteration resends everything, so a twenty-step run costs far more than twice a ten-step run.

Both push the same direction: fewer, more reliable steps beat more steps. Checkpointing matters for the same reason — a failure at step 8 should not discard steps 1 through 7.

Practical shape

For most work: shallow plan, explicit goal restated each iteration, a tried-approaches list, re-planning when assumptions break, checkpoints, and a hard iteration cap.

Skip planning entirely for one-to-three step tasks — it adds tokens and latency for nothing.

And if the sequence is known in advance, do not use an agent. Write the workflow. Planning machinery exists for cases where the path genuinely cannot be known ahead of time.

What to remember

• Plan-first gives coherence and inspectability, and fails by following plans that stopped applying.
• React-as-you-go adapts fully, and fails by drifting and repeating.
• Practical answer: shallow plan, revised — plus restating the goal every iteration and tracking what has been tried.
• Decompose large tasks into subtasks with separate contexts; it is the only thing that scales.
• Reliability compounds downward and context grows quadratically — both favor fewer, better steps.

Next: How Agents Fail