Task decomposition is where agent plans go to die
When a long-horizon agent run fails, the execution trace gets the blame — the bad tool call, the hallucinated parameter, the step that errored. But run the autopsy honestly and the decomposition usually committed the crime. The plan's structure was wrong before any step executed, and everything downstream was the structure playing itself out.
Decomposition is two decisions, not one: identify the sub-tasks, then order them. Both are schema decisions. Choosing granularity is choosing the unit of work; choosing dependencies — sequential, conditional, aggregation — is choosing the DAG the run will follow. And structural errors behave differently from execution errors. A failed step costs you that step and a retry. A wrong decomposition costs you the run, because every subsequent step inherits the flaw: the missing dependency surfaces as a step executing against stale assumptions, the wrong grain surfaces as an agent drowning in scope or starving for context.
The failure modes have names. Over-decomposition — excessive granularity — buys coordination overhead with nothing in return: every sub-task boundary is a serialization event where context gets summarized, re-grounded, and taxed for tokens, and each boundary is a fresh opportunity for misunderstanding. Under-specification leaves sub-task descriptions vague enough that the executing agent fills gaps with assumptions — confidently, silently, and each leaf differently. And goal propagation loss is the quietest killer: the parent goal gets paraphrased into child tasks like a game of telephone, until a leaf agent executes its literal instruction perfectly while the mission it was supposed to serve fails. The research measures this as plan quality — the percentage of plans that lead to successful execution — and it's telling that most teams instrument step success meticulously while never measuring plan quality at all.
The prescription follows from treating the plan as an artifact rather than a private thought. Make the dependency graph explicit, so aggregation points and orderings are inspectable before execution spends money on them. Type the data flow between tasks, so what step B needs from step A is a contract, not an inference. Carry the parent goal verbatim into every child, not a summary of it. Size sub-tasks by testability — a sub-task is right-sized when you can write its acceptance check, which is the same heuristic that makes evals function as contracts. And run reflection on the plan before executing it: a critique pass over a decomposition is the cheapest verification step in the whole system, because it happens before the expensive part.
The concession: some tasks genuinely resist upfront decomposition, because the information needed to plan step three only exists after step two runs. Research and debugging tasks are like this structurally. There, the plan-execute-observe loop with cheap replanning beats any static plan, and the skill shifts from planning well to noticing quickly that the plan is wrong — backtracking to the parent task is a feature, not an admission of defeat. Static-plan purity is its own failure mode; I'm arguing for decomposition discipline, not decomposition ceremony.
What I'm not conceding is that better models dissolve the problem. Reasoning models changed the economics of planning — plans got cheaper to generate and regenerate — but a cheaper way to produce an unmeasured artifact just produces more unmeasured artifacts. The teams whose agents survive long horizons are the ones who noticed that agents lose the plot exactly where the plot was never written down: in the structure connecting one step to the next.