Plan first, or just start?

Two shapes of loop

Interleaved. The model takes one step, sees the result, decides the next. No plan exists; the next action is always chosen with the freshest evidence available. This is what most agent loops do by default.

Plan then execute. The model first writes an ordered list of steps, and the loop works through it. This buys three things that matter operationally. You get an artefact you can inspect before any action is taken, which means a person can approve an intention in ten seconds instead of approving twenty individual steps. You can refuse a plan mechanically: scan it for forbidden actions and stop before anything happens. And independent steps can run in parallel, which interleaving cannot do because each step waits for the last.

Neither is correct in general. The choice turns on how much you know before you start.

The trap in planning

A plan written before the first tool result is a guess about a world the agent has not looked at yet. That would be harmless, except for what happens next: the plan is now in the transcript, in the agent’s own voice, and consistency with its own earlier text is a strong pull on what it generates later.

So the characteristic failure looks like this. Step two returns evidence that the assumption behind steps three to five was wrong: the customer record does not exist, the file has a different schema, the API returns an empty list. And the agent proceeds to step three anyway, sometimes writing a sentence acknowledging the problem before continuing as planned. People find this baffling. It is the most predictable behaviour in the system: the plan is text, the contradiction is text, and there is more of the former.

The fix is structural

Take the plan out of the transcript and make it state your harness owns.

Keep a list of steps in a file or a variable. Show the model only the current step and the remaining ones, not the original paragraph. After each step, run an explicit re-plan checkpoint: hand the model the current step’s result and the remaining steps, and ask a narrow question: does the remaining plan still make sense given this result; if not, return a revised list. Because the old plan is not sitting in front of it as its own prior commitment, revision is cheap rather than a reversal.

The same file gives you three side effects worth having: a progress display for whoever is watching, a resume point if the process dies at step four, and a natural place for the budget to live.

Decomposition has a ceiling

Splitting a task into more steps does not make it easier. Per-step reliability multiplies, so twelve steps at 95 per cent each is about 54 per cent end to end, and eight steps at 98 per cent is 85 per cent. Every additional step is a coin flip you have added to the chain.

This has a blunt implication that cuts against how decomposition is usually taught: the shortest plan that could work is generally the best one, and combining two steps into one tool call is often a bigger reliability win than any prompt change. If a plan has fifteen steps, the useful question is which of them your code could do without asking a model at all.

What the evidence actually says about thinking aloud

Asking a model to reason before answering helps on some tasks (multi-step arithmetic and constraint problems especially) and does little on others, including many extraction and classification tasks where the answer is a lookup. Newer models trained to reason internally complicate it further: asking them to produce an explicit plan on top can add tokens and latency for no gain, and occasionally makes things worse by anchoring them early.

The honest position is that this is task-dependent and cheap to test. Run your fixed set of tasks both ways and keep the version that wins. That measurement takes an afternoon and settles an argument that otherwise runs for months.

A rule of thumb

Plan first when the environment is known and the risk of acting is high: a deployment, a set of database migrations, anything a person should sign off. Interleave when the environment is unknown and each action is cheap and reversible: reading files, searching, exploring an API. Most real agents want both: a short plan for the shape of the work, re-derived at each checkpoint, with free-form interleaving inside each step.