Why do well-specified tasks work so much better?

Because the split is already made, which removes the step most likely to fail. Migrations and repetitive fixes are reported as the reliable cases for exactly that reason: the work is not simpler, but nobody has to infer what the pieces are, so there is no inference to get wrong.

Can the plan be checked before it runs?

On the products that show it, yes, and that is the cheapest place to intervene. Reviewing a plan takes a fraction of the time reviewing the output does, and it catches the misreading while it is still a paragraph rather than after it has become a body of finished work.

Is too fine a split safer than too coarse?

It is a different failure, not a safer one. Fine splits produce long runs where each handover loses a little context and the cost accumulates across turns that achieved little individually. Coarse splits produce steps too large to do well. Both are common and neither is the conservative choice.

Glossary

Task decomposition

Task decomposition is breaking a goal into steps small enough to act on, and it is where most such failures begin rather than where they become visible.

In plain terms

Turning do this into a list of things that can each be done. A system handed a large goal has to produce that list before it can act, and everything afterwards is built on it. A sensible list makes the rest look easy. A list that missed something produces confident work that solves a slightly different problem.

Why it matters

Because a bad split does not announce itself. Each step afterwards can be executed perfectly, so the run looks orderly the whole way through and the output is coherent. The mismatch only surfaces when somebody compares the result against what was actually wanted, which is usually at the end, after the whole thing has been paid for.

How it works

It happens first and everything inherits it. The agent forms a plan from the brief, and each subsequent decision is made inside that plan rather than against the original goal. A step that should have existed and does not will not be discovered later, because nothing afterwards is looking at the goal any more.

Vagueness in the brief becomes confident structure in the plan, which is the part people find counter-intuitive. An underspecified request does not produce hesitation; it produces a plan that resolves the ambiguity in some particular direction and then proceeds as though that was what was asked. One vendor puts the consequence in commercial terms, describing vague tasks as expensive lessons under compute-unit billing.

Splitting too finely fails differently from splitting too coarsely, and both are real. Too coarse and a step is beyond what a single action can accomplish, so it is attempted badly. Too fine and the run becomes long, each handover loses a little context, and the cost accumulates over turns that individually achieved very little.

It is where the well-specified backlog earns its reputation. Migrations, dependency upgrades and repetitive fixes are the cases agents are consistently reported to handle well, and what those share is that the split is obvious before anybody starts. The work is not easier; the decomposition is already done, which removes the step most likely to go wrong.

Where the failure is, and where it is found

This gap is the argument for looking at plans, and it is a stronger argument than it first appears. The intuition is that reviewing a plan is a formality compared with reviewing the work, and in a sense that is right: a plan is a paragraph and the output may be a great deal of material. But the two are not alternatives with different thoroughness, they are interventions at opposite ends of a chain where the information is identical and the cost is not. Everything that will be wrong about the finished work is already determined by the plan, which means reading it settles the same question the final review settles, minutes in rather than at the end, before any tokens have been spent acting on it. The products that surface the plan before executing are offering the cheapest available check, and the reason it is so often skipped is that at that moment there is nothing yet to be suspicious of.

Seen in the wild

A general agent that plans and executes end to end from a brief, where you review what comes back rather than steering each turn.
Manus
An autonomous engineer whose sweet spot is the well-defined backlog, and whose documentation warns that compute-unit billing makes vague tasks expensive lessons.
Devin Cloud
A framework where agents are given roles, goals and tools, so the division of a job is expressed before anything runs.
CrewAI

Common misconceptions

People assume

A failure here shows up as the agent getting stuck.

In fact

It shows up as a confident, complete answer to a slightly different question. Getting stuck is the visible failure and the cheaper one. A wrong split produces orderly work throughout, which is why the run gives no signal and the problem is found by whoever compares the output with the original request.

People assume

A better model decomposes better, so this improves on its own.

In fact

It improves the plan drawn from a given brief and cannot improve the brief. Where the request left something unstated, a stronger model resolves the ambiguity more fluently rather than noticing it, and fluency is exactly what makes the resulting plan harder to question.

Telling them apart

Task decomposition vs Planning

Task decomposition

Breaking the goal into actionable pieces.

Planning

Working out the order and approach before acting.

Decomposition decides what the pieces are; planning decides what to do with them. A good plan over the wrong pieces still goes wrong.

Questions

Why do well-specified tasks work so much better?: Because the split is already made, which removes the step most likely to fail. Migrations and repetitive fixes are reported as the reliable cases for exactly that reason: the work is not simpler, but nobody has to infer what the pieces are, so there is no inference to get wrong.
Can the plan be checked before it runs?: On the products that show it, yes, and that is the cheapest place to intervene. Reviewing a plan takes a fraction of the time reviewing the output does, and it catches the misreading while it is still a paragraph rather than after it has become a body of finished work.
Is too fine a split safer than too coarse?: It is a different failure, not a safer one. Fine splits produce long runs where each handover loses a little context and the cost accumulates across turns that achieved little individually. Coarse splits produce steps too large to do well. Both are common and neither is the conservative choice.

Key takeaways

It happens first, and every later decision is made inside it rather than against the goal.
A wrong split produces confident, orderly work on a slightly different problem.
Vagueness becomes structure: the model resolves ambiguity rather than noticing it.
Too fine and too coarse are both real failures, with different shapes.
Well-specified backlogs work because the decomposition is already done.

Tools that use this

Manus
Plans and executes end to end from a brief you review afterwards.
Devin Cloud
The well-defined backlog as its sweet spot; vague tasks as expensive lessons.
CrewAI
Roles, goals and tools expressing the division before anything runs.