Give an agent a large, vague task — "modernise this service" — and you get a shallow pass at several things and completion at none. The model has no notion of what finished looks like, so it does some work and stops.
Break the same task into pieces with explicit boundaries and completion conditions, and the behaviour changes entirely. Decomposition is unglamorous and it is most of what makes agents work on real problems.
What changed in 2026
- Plan-then-execute overtook decide-as-you-go. Producing an explicit plan before acting proved more reliable and gave a natural point for human review.
- Structured plans replaced prose. Machine-readable plans with dependencies and completion criteria became the norm over free-text step lists.
- Delegation made boundaries matter more. Once pieces go to subagents, a vague boundary becomes a wrong result rather than a slightly worse one.
- Over-decomposition got recognised. Teams found that splitting too finely produced coordination overhead exceeding any benefit.
Decompose on dependencies
The instinct is to split by size — chop a big task into equal chunks. The useful axis is dependency.
Ask, for each pair of pieces: does one need the other's output? If yes, they are sequential and no amount of parallelism changes that. If no, they are independent and can run concurrently.
| Structure |
Execution |
Notes |
| Independent pieces |
Parallel |
The case that actually benefits from fan-out |
| Chained pieces |
Sequential |
Parallelising adds coordination for nothing |
| Fan-out then merge |
Parallel, then one |
Common and effective |
| Mutually dependent |
Do not split |
Keep together |
That last row matters. Two pieces that each need the other's result are not two tasks — they are one task with an internal loop, and splitting them produces an agent that ping-pongs between halves without converging.
Getting this right determines whether subagent architecture helps or hurts, since delegation only pays on genuinely independent work.
Every piece needs a finish line
The second requirement, and the one most often missing: each piece needs a condition that says it is done, checkable without judgement.
Compare:
- "Improve error handling" — no end state, no way to know when to stop.
- "Add a typed error return to every exported function in
parser/, and confirm the package compiles" — checkable, bounded, unambiguous.
The second is a task an agent can complete and you can verify. The first is an invitation to wander.
This matters most for delegated work. A subagent gets one shot with no ability to ask what you meant, so a vague completion condition returns confidently wrong work rather than a question.
Plan, review, execute
The shape that works well in practice separates deciding from doing.
Plan. The agent produces a structured plan — pieces, dependencies, completion conditions — without executing anything. Cheap, fast, and entirely reversible.
Review. A human, or a verifier, checks the plan. This is the highest-leverage review point available: catching a wrong plan costs one cheap call, catching a wrong execution costs everything already done. It also fits naturally with human-in-the-loop approval, since a plan with concrete steps is far more reviewable than an intention.
Execute. Work through the plan, tracking which pieces are complete. That tracking is also what makes resumption possible after a failure — see agent replay and checkpoints.
The alternative — deciding the next step at each step — is more flexible and much harder to review, budget, or resume.
Common mistakes
- Splitting by size rather than dependency. Parallelising work that is inherently sequential.
- Pieces with no completion condition. The agent cannot tell when to stop.
- Over-decomposition. Coordination cost exceeds the benefit.
- Splitting mutually dependent work. Produces oscillation, not progress.
- No plan artefact. Nothing to review, budget against, or resume from.
- Decomposing a task that fits in one pass. Pure overhead.
FAQ
How small should pieces be?
Small enough to have an unambiguous completion condition, large enough that the coordination overhead is worth it. If a piece takes one tool call, it is probably a step rather than a task.
Should the model generate the plan or should I?
The model, for tasks whose structure varies. You, for tasks with a known shape — at which point it is a workflow rather than an agent, which is cheaper and more predictable.
What if the plan turns out wrong mid-execution?
Allow replanning, and cap how often. An agent that replans at every obstacle never finishes; one that cannot replan at all fails on the first surprise.
Does this reduce cost?
Usually yes, indirectly — bounded pieces with clear endpoints converge faster than open-ended wandering, and the plan gives you something to budget against per agent token budgets.
Where to go next
For running independent pieces concurrently, read subagent architecture. For the alternative when structure is known in advance, prompt chaining vs agents, and for resuming a partially-executed plan, agent replay and checkpoints.