The Planner That Plans Too Much: When Upfront Decomposition Hurts
An agent found the root cause in step one and executed the remaining seven steps anyway. Plans in context outweigh the evidence that should kill them — unless revision is something the loop can actually do.
An agent asked to investigate a slow endpoint produced an eight-step plan before touching a single tool. Step one found the cause. It then executed steps two through eight anyway.
Upfront decomposition is a strong pattern applied to the wrong shape of task more often than any other. The failure isn't that the plan is bad — the plan is usually reasonable given what was known. The failure is that it was made when nothing was known, and then treated as binding.
Why plans stick after they should be abandoned
Once a plan is in the context, every subsequent turn re-reads it. It sits there as an explicit, structured commitment — often the most structured thing in the array — while the evidence that should overturn it arrives as unstructured tool output scattered among other results.
The model isn't being stubborn. It's weighing a clear stated intention against diffuse contradicting evidence, and the clear thing wins. Add any prompt language about following the plan or being thorough and the effect strengthens.
The visible symptoms:
- Steps executed after their purpose is gone, as in the investigation above.
- Findings that contradict the plan get noted and then not acted on.
- A plan built on a wrong assumption in step one propagates through every later step, because nothing in the loop re-examines the assumption.
Match the planning to the task's shape
Known structure, unknown content → plan upfront. Processing forty invoices, running a defined checklist, executing a documented runbook. The steps are knowable in advance because they don't depend on what you find. Planning here buys parallelism, progress tracking, and something a human can approve before execution starts.
Unknown structure → don't. Debugging, investigation, research, anything where step one's result determines whether step two exists. The honest plan is "look at the most likely thing, then decide," and elaborating it into eight steps manufactures confidence that isn't there.
The distinguishing question: could a competent person write this plan without doing any of the work? If no, the agent can't either — it will produce a plausible-sounding plan, which is worse than no plan, because plausible plans get followed.
What to do instead for unknown-structure work
Plan one step ahead, with a stated hypothesis.
hypothesis: the slowdown is in the database layer
next_step: check query timings on the endpoint's three queries
this_tells_me: whether to look at the DB or move to the network path
Cheap, revisable, and it produces the same benefit people want from planning — visible reasoning — without the lock-in. The this_tells_me field matters: it forces the step to be diagnostic rather than busywork, and makes an uninformative step obvious before it runs.
Make abandonment a first-class move. Give the loop an explicit way to record it:
revise_plan(reason: "step 1 found the cause: connection pool exhausted",
dropping: ["step 2", ..., "step 8"],
new_next: "confirm pool config and check for a leak")
Revision now leaves a trace, which means you can measure it. ⚠️ A long-running investigative agent that never calls revise_plan is not being efficient — it's not noticing.
Re-state the goal, not the plan, at each turn. If the loop injects standing context every turn, make it the objective and the constraints. Let the plan live in the mutable part of the history where new evidence can outweigh it.
Where upfront planning genuinely wins
Worth being clear that the pattern isn't broken:
- Human approval before action. A plan a person can review and authorize is the whole point of the pattern for consequential work.
- Parallel dispatch. You can't fan out over independent subtasks without enumerating them first.
- Cost prediction. A plan gives you a step count to budget against and to compare against actual.
- Repeated, structured jobs. When the same shape of task recurs, the plan is closer to a template than a guess — and at that point, consider whether it should be code.
The takeaway
Planning is a bet that the future is predictable enough to enumerate. For structured work that bet pays. For investigation it doesn't, and the cost isn't just the wasted planning turn — it's an agent that follows a stale plan past the evidence that invalidated it. Plan one step ahead with a hypothesis, make revision an explicit and traceable act, and count revisions as a health metric rather than a mistake.