{"course":{"slug":"agents-and-automation","title":"Agents and Automation","url":"https://addaly.com/learn/agents-and-automation","level":"intermediate","track":"build"},"lesson":{"slug":"planning-and-decomposition","title":"Plan first, or just start?","url":"https://addaly.com/learn/agents-and-automation/planning-and-decomposition","position":15,"of":72,"minutes":9,"answer":"A plan written into the transcript becomes something the model has to stay consistent with, so keep the plan as harness-owned state that is re-derived when evidence contradicts it.","keyIdea":"A plan written into the transcript becomes something the model has to stay consistent with, so keep the plan as harness-owned state that is re-derived when evidence contradicts it."},"body":{"format":"markdown","text":"## Two shapes of loop\n\n**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.\n\n**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.\n\nNeither is correct in general. The choice turns on how much you know before you start.\n\n## The trap in planning\n\nA 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.\n\nSo 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.\n\n## The fix is structural\n\nTake the plan out of the transcript and make it state your harness owns.\n\nKeep 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.\n\nThe 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.\n\n## Decomposition has a ceiling\n\nSplitting 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.\n\nThis 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.\n\n## What the evidence actually says about thinking aloud\n\nAsking 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.\n\nThe 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.\n\n## A rule of thumb\n\nPlan 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."},"check":{"question":"An agent writes a five-step plan. The second tool result shows that the assumption behind steps three to five was wrong, and it carries on with the original plan anyway. What is the most reliable fix?","options":[{"text":"Add an instruction telling it to adapt the plan whenever new information contradicts it.","correct":false,"tempting":"Sends the correction down the same text channel that is being outweighed; the agent’s own earlier plan is still sitting in the transcript pulling the other way."},{"text":"Ask for a longer and more detailed plan up front, so fewer assumptions are left implicit.","correct":false,"tempting":"More detail written before any evidence arrives is more guesswork, and more text for the model to stay consistent with."},{"text":"Move the plan out of the transcript into harness-owned state, showing only the remaining steps and re-deriving them at a checkpoint after each result.","correct":true},{"text":"Split the work between a planning agent and an executing agent so the roles are separated.","correct":false,"tempting":"Buys a separate context window, but the executor is still handed the same stale plan as its instructions and has even less of the evidence."}]},"prev":{"slug":"the-loop","title":"Plan, act, observe, repeat","url":"https://addaly.com/learn/agents-and-automation/the-loop"},"next":{"slug":"designing-a-tool-surface","title":"Tools that survive being called by a machine","url":"https://addaly.com/learn/agents-and-automation/designing-a-tool-surface"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Plan first, or just start?', in Agents and Automation. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/agents-and-automation/planning-and-decomposition (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Plan first, or just start?","courseTitle":"Agents and Automation","module":{"index":2,"slug":"how-the-loop-runs","title":"The machinery: transcript, tools, loop"},"answer":null,"keyIdea":"A plan written into the transcript becomes something the model has to stay consistent with, so keep the plan as harness-owned state that is re-derived when evidence contradicts it.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"two-shapes-of-loop","runs":[{"text":"Two shapes of loop"}]},{"t":"p","runs":[{"text":"Interleaved.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Plan then execute.","b":true},{"text":" 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 "},{"text":"before","i":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Neither is correct in general. The choice turns on how much you know before you start."}]},{"t":"h2","id":"the-trap-in-planning","runs":[{"text":"The trap in planning"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-fix-is-structural","runs":[{"text":"The fix is structural"}]},{"t":"p","runs":[{"text":"Take the plan out of the transcript and make it state your harness owns."}]},{"t":"p","runs":[{"text":"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: "},{"text":"does the remaining plan still make sense given this result; if not, return a revised list","i":true},{"text":". Because the old plan is not sitting in front of it as its own prior commitment, revision is cheap rather than a reversal."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"decomposition-has-a-ceiling","runs":[{"text":"Decomposition has a ceiling"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"This has a blunt implication that cuts against how decomposition is usually taught: "},{"text":"the shortest plan that could work is generally the best one","b":true},{"text":", 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."}]},{"t":"h2","id":"what-the-evidence-actually-says-about-thinking-aloud","runs":[{"text":"What the evidence actually says about thinking aloud"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"a-rule-of-thumb","runs":[{"text":"A rule of thumb"}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"An agent writes a five-step plan. The second tool result shows that the assumption behind steps three to five was wrong, and it carries on with the original plan anyway. What is the most reliable fix?"}],"options":[{"text":[{"text":"Add an instruction telling it to adapt the plan whenever new information contradicts it."}],"correct":false,"tempting":[{"text":"Sends the correction down the same text channel that is being outweighed; the agent’s own earlier plan is still sitting in the transcript pulling the other way."}]},{"text":[{"text":"Ask for a longer and more detailed plan up front, so fewer assumptions are left implicit."}],"correct":false,"tempting":[{"text":"More detail written before any evidence arrives is more guesswork, and more text for the model to stay consistent with."}]},{"text":[{"text":"Move the plan out of the transcript into harness-owned state, showing only the remaining steps and re-deriving them at a checkpoint after each result."}],"correct":true,"tempting":null},{"text":[{"text":"Split the work between a planning agent and an executing agent so the roles are separated."}],"correct":false,"tempting":[{"text":"Buys a separate context window, but the executor is still handed the same stale plan as its instructions and has even less of the evidence."}]}],"order":[0,2,1,3],"why":null},"prev":{"slug":"the-loop","title":"Plan, act, observe, repeat","minutes":7},"next":{"slug":"designing-a-tool-surface","title":"Tools that survive being called by a machine","minutes":9}}}