1.6 Task Decomposition Strategies

Every substantial task an agent faces has to be broken into smaller steps — you can't review a 50-file pull request or audit a legacy codebase in one breath. Task Statement 1.6 is about HOW you break the work apart, which is a real design decision with real consequences. Choose the wrong way to slice a job and the agent either can't adapt when surprises appear, or it does shallow, inconsistent work.

Here's the intuition. Think about two very different kinds of project. Cooking from a recipe: the steps are fixed and known in advance — chop, sauté, simmer, plate — and you do them in order every time. Now think about exploring an unfamiliar city with no map: you can't list the steps up front, because each turn reveals what to do next — you see an interesting street, follow it, discover a market, adjust. Some tasks are recipes; some are explorations. The skill is recognising which kind of task you have, because each wants a different decomposition strategy.

On top of that choice sits a sneaky failure mode that no bigger model can fix — where an agent asked to handle many items in one go quietly does a worse job on the later ones. We'll build up both ideas: first the two strategies and how to choose, then the failure mode and its only real cure.

The first strategy is the recipe approach, formally called a fixed sequential pipeline (or prompt chaining). You decide the steps in advance and the agent executes them in a set order, each step feeding the next. A document-processing flow might be: extract the text → classify the document → pull out the key fields → validate. Same steps, same order, every time.

This shines when the task is predictable and structured — you genuinely know up front what needs to happen. Its strengths are exactly what you'd want from a recipe: it's consistent (same process every run), it's debuggable (when something breaks, you know which step), and it's repeatable. A classic example is a multi-aspect code review broken into 'analyse each file individually, then run a cross-file integration pass' — predetermined stages you can rely on.

Its weakness is the flip side of its strength: it can't adapt. If step 2 turns up something that should change the whole plan, a fixed pipeline plows ahead with the steps it was given. For a predictable task that's fine — nothing surprising was going to happen anyway. For an open-ended one, that rigidity is a liability.

The second strategy is the exploration approach: dynamic adaptive decomposition. Instead of fixing the steps in advance, the agent generates its next subtasks based on what it has just discovered. The plan grows and bends as understanding deepens — exactly like exploring that unfamiliar city.

This is the right choice for open-ended tasks where you genuinely can't know the steps ahead of time: exploring a legacy codebase, running a security audit, doing broad research. Take 'add comprehensive tests to a legacy codebase.' A dynamic approach starts by mapping the structure, then identifies the high-impact areas, then builds a prioritised plan — and that plan keeps adapting as it discovers dependencies it couldn't have predicted at the start. You couldn't have written those steps in advance because you didn't yet know what the codebase contained.

Its trade-off is the mirror of the pipeline's: it adapts beautifully but is less predictable, harder to reproduce exactly, and a little harder to debug. That's a price worth paying for open-ended work — and a price not worth paying for a predictable task, where it would just add needless unpredictability to something a simple recipe handles perfectly.

Now the failure mode that catches people, because the obvious fix is the wrong one. Imagine asking an agent to review a 14-file pull request all in a single pass. You get back something strange: detailed, careful feedback on the first few files, then increasingly thin comments on the later ones — and sometimes outright contradictions, like flagging a pattern as a bug in file 3 while waving through identical code in file 11. What happened?

This is attention dilution. When a model spreads its attention across many items in one pass, the quality thins out across them — strong early, weak late. It's a little like a person proofreading 60 pages in one sitting: by page 50 they're skimming, and they've stopped holding page 3 in mind well enough to stay consistent with it. The crucial insight is the ROOT CAUSE: it's about finite attention spread thin, NOT about running out of room. The model didn't hit a size limit; it just couldn't attend deeply to everything at once.

And that's exactly why the tempting fix fails. People reach for a bigger model or a larger context window — but those add CAPACITY (more room), and capacity was never the problem. The fix has to address attention QUALITY, and the way you do that is structural: split the work. Do a separate focused pass per item (review each file on its own, so each gets full attention), then a separate cross-item integration pass (examine how the files interact). This multi-pass approach is one of the most important patterns in the whole exam — it returns in Domain 4 (reviewing output) and Domain 5 (exploring codebases).

The 1.6 traps reward one habit of mind: recognising when a problem is STRUCTURAL (fixed by how you split the work) rather than a CAPABILITY problem (fixed by a better model or prompt). The wrong answers almost always offer more capability; the right one almost always restructures the work.

Watch especially for the 'bigger model / larger context window' distractor on an attention-dilution question — it's designed to be tempting because it sounds like more power solves everything. It doesn't, because the bottleneck is attention quality, not capacity. And watch for strategy mismatches: a fixed pipeline forced onto an open-ended audit (can't adapt), or dynamic decomposition imposed on a predictable flow (needless unpredictability).

You now have the two strategies and how to choose between them, plus attention dilution and its only real cure. The exercise is built around feeling the failure first-hand — once you've watched the quality visibly thin out across a single big pass and then snap back when you split it, the bigger-model distractor will never tempt you again.

Decomposition is about structuring the work before it runs. The final lesson of Domain 1, 1.7, turns to what happens BETWEEN runs — how to resume, branch, and avoid the trap of carrying stale information forward when you pick a task back up.