Planning & Reasoning
Decomposition, plan-and-execute, reflection, and self-correction — how to stop an agent wandering on long tasks
Planning & Reasoning
TL;DR
An agent that only reacts one step at a time tends to drift on long tasks — it forgets the original goal, repeats work, or declares victory early. Planning fixes this by giving the agent something to measure itself against. The trade-off is real: a plan written before seeing any data can be wrong, so the agent must be allowed to revise it.
| Property | Value |
|---|---|
| Level | Intermediate |
| Reading time | ~20 minutes |
| Prerequisites | The Agent Loop |
| You will understand | Decomposition, plan-and-execute, reflection, and when each pays off |
The Problem Planning Solves
Watch what happens to a plain ReAct agent on a long task:
Task: "Research this supplier and flag any compliance risks."
Step 1: Search company name. ✓ sensible
Step 4: Search company name again. ← repeating itself
Step 7: Reading a news article. ← interesting, but why?
Step 11: Looking up a subsidiary. ← has it forgotten the goal?
Step 15: "Here is a summary." ← never checked compliance at allNothing errored. Every individual step looked reasonable. The agent simply had no representation of the overall goal beyond the original message, which by step 15 is buried under fourteen observations.
This is the characteristic failure of long agent runs, and it is nearly invisible in testing. Short tasks work fine, so the problem only appears on the hard cases you care most about.
Decomposition — break the goal into parts
The simplest form of planning. Before acting, split the goal into named subtasks.
Goal: Research this supplier and flag compliance risks.
Subtasks:
1. Identify the legal entity and its parent company
2. Check sanctions and watchlists
3. Check for recent regulatory actions
4. Check financial stability signals
5. Summarise the risks found| Benefit | Why |
|---|---|
| Progress is visible | The agent (and you) can see what is done and what remains |
| Stopping becomes obvious | Finished means all subtasks complete — a concrete test |
| Drift is detectable | An action that fits no subtask is a warning sign |
| Parts can run in parallel | Independent subtasks do not need to be sequential |
Plan-and-Execute
Make the whole plan first, then carry it out. Compare the two shapes:
Two shapes of agent
ReAct — decide one step at a time
Flexible and adapts immediately to what it learns. Cheaper for short tasks. Drifts on long ones, because nothing holds the overall goal.
Plan-and-execute — plan first, then act
RecommendedStays on target, gives visible progress, and makes stopping concrete. Costs one extra call up front, and the plan may be wrong because it was made before seeing any data.
Plan-and-execute
Roughly three steps is the crossover. Below that, planning costs more than it saves. Above it, the plan usually pays for itself by preventing repeated work and early stopping.
Replanning
A plan made before seeing any data will sometimes be wrong. That is expected, not a failure.
| Trigger | Response |
|---|---|
| A subtask turns out impossible | Drop it, note why, continue |
| New information changes the goal | Revise the remaining plan |
| A tool keeps failing | Find another route or hand off |
| The plan is finished but the goal is not met | Replan from what you now know |
Cap replanning too. An agent allowed to replan freely can loop at a higher level — planning, failing, replanning, failing — burning far more than a simple tool loop would. Two or three replans is usually plenty.
Reflection — checking its own work
Reflection is a step where the agent reviews what it just produced before continuing.
Reflection loop
Act
Produce something — an answer, a draft, a result
Reflect
Is this right? Complete? Does it actually answer the question?
Revise
Fix what the reflection found
Deliver
Once it passes its own check
| Works well for | Works poorly for |
|---|---|
| Writing and analysis | Simple factual lookups |
| Code, where errors are checkable | Anything where the first answer is nearly always right |
| Multi-part answers where something gets missed | Tasks under tight latency budgets |
| Judgement calls with no single right answer | Cases where the model cannot tell good from bad |
Reflection only helps when the model can actually judge the thing. Asking a model to check its own arithmetic often produces a confident re-endorsement of the same wrong answer. Where a real check exists — run the code, validate against a schema, re-query the source — use that instead. A real check beats self-assessment every time.
Making reflection work
| Technique | Why |
|---|---|
| Ask for specific checks | "Does this answer all three parts?" beats "is this good?" |
| Use a separate critic | A fresh call without the generator's context is more critical |
| Give it a checklist | Concrete criteria produce concrete findings |
| Cap the rounds | Two is usually enough; more rarely improves anything |
| Prefer a real verifier | Running the tests beats asking whether the code looks right |
Choosing an Approach
| Task shape | Use |
|---|---|
| One or two steps, known | No planning. Plain loop or a workflow. |
| Several steps, path depends on results | ReAct |
| Long, multi-part, drifts in testing | Plan-and-execute |
| Quality matters more than cost | Add reflection |
| Unreliable tools or environment | Plan with replanning |
| Independent subtasks | Decompose and parallelise |
What each coordination pattern costs
No agent at all. One prompt, one answer. Always try this first.
Read the task and answer it
Wall-clock time so far
0 ms
One call was 900 ms
Cost so far
0.00 units
One call was 1.00
Run them all. Two results are worth sitting with: the router can beat a single call on cost, because it sends easy work somewhere cheap. And parallel workers cost three times more but finish almost as fast as one, because you wait for the slowest, not the sum.
Common Mistakes
What goes wrong
Planning a two-step task
Pure overhead. The plan costs a call and saves nothing.
A plan that cannot be revised
The plan was made before any data existed. Locking it in means one wrong assumption dooms the whole run.
Uncapped replanning
A higher-level loop that burns budget faster than the tool loop it was meant to fix.
Reflection where the model cannot judge
Self-checking arithmetic or facts often just re-endorses the error with more confidence.
Self-critique when a real check exists
If you can run the tests, run the tests. Do not ask the model whether the code looks correct.
Plan kept only at the start of the context
By step 12 it is buried and effectively forgotten. Restate the remaining plan near the end of each request.
Concept Checks
Check yourself
Why does a plain ReAct agent drift on long tasks?
Because the only representation of the goal is the original message, and by step twelve that sits far back in a context filled with observations. Each individual decision is made against recent material, so the agent optimises locally and loses the thread. A plan fixes this by creating an explicit, checkable structure that can be restated near the end of every request, where the model attends to it reliably.
Why must a plan be revisable, and why must revision be capped?
Revisable because the plan was written before any tool ran, so it encodes guesses about what the data would look like. Locking it in means one wrong assumption ruins the run. Capped because replanning is itself a loop: an agent that can always start over will plan, fail, replan, and fail again, burning more budget than the simple loop it was meant to control. Two or three revisions is normally enough.
When does reflection genuinely improve quality, and when is it theatre?
It helps when the model can actually evaluate the artefact — spotting a missing section, an unsupported claim, or an unaddressed part of the question. It is theatre when the model has no better basis for judging than it had for producing, which is typically the case for arithmetic and factual recall: the self-check tends to restate the original error more confidently. Where a real verifier exists, use it instead.
A task has five independent subtasks. What does decomposition buy beyond organisation?
Three concrete things. Parallelism, since independent subtasks can run at once and you wait for the slowest rather than the sum. A real finish condition, because "all five complete" is testable in a way that "seems done" is not. And drift detection, because any action that maps to no subtask is a visible warning rather than something you only notice in the final output.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| Drift | The characteristic failure of long ReAct runs |
| Decomposition | Split the goal into named subtasks |
| Plan-and-execute | Plan first, then work through it |
| The crossover | Around three steps — below it, planning costs more than it saves |
| Replanning | Necessary, because the plan predates the data — but cap it |
| Reflection | Review before delivering; works only where the model can judge |
| Real checks beat self-checks | Run the tests rather than asking if the code looks right |
| Restate the plan late | Keep it where the model reads reliably |
Next
Planning needs something to plan against, and the model forgets everything between calls: Memory.