任务分解Task Decomposition: How Fine to Cut?

A research agent was given one job: write a report on the competitive landscape of an industry. Wanting to be thorough, the lead split the work very fine, company by company, then revenue, products and recent moves as separate pieces, layer under layer until there were dozens of sub-tasks. The sub-tasks then spent their time waiting and passing messages, and when the report was finally assembled, the pieces did not agree with each other: the definitions differed from section to section. (Illustrative example.)

What this lesson covers

• Why splitting is not optional: a context that cannot hold the work, a single trajectory that cannot be trusted, and the failure isolation only a split task gives you
• Granularity, the core feel of the lesson: one sub-task, one deliverable that can be accepted on its own, and the field test that tells you the cut was too fine
• The contract every sub-task carries: input, output, and how failure gets reported, settled in advance, never improvised
• A working order in four steps: list the final deliverable, work backwards, write the contracts, draw the dependencies and check for cycles
• The two exam shapes: the circular dependency, and granularity so fine that communication eats the work

Chapters

• 00:08 Opening incident: the report that was split to pieces
• 03:11 Granularity: how fine to cut
• 04:35 The contract every sub-task carries
• 07:22 What a bad split looks like on the exam
• 09:32 The production checklist
• 10:45 Next lesson: 1.4, topologies

Core diagram

The five traps

1. Splitting by tool: one sub-task per tool, so the split follows the implementation instead of the deliverable.
2. A goal with no contract: "go and research this part", with the input, the output, and the failure handling all left to the executor's imagination.
3. Nobody owns the whole after the split: each sub-task delivers its own piece, and at assembly time the definitions clash and the conclusions fight, with nobody responsible for consistency.
4. Papering over a circular dependency with a timeout: when the wait times out, some number gets filled in and the run carries on, dressing a deadlock up as slowness.
5. The finer-is-better compulsion: believing that a finer split is a more professional split, and never counting the communication bill.

The production checklist

1. Every sub-task names exactly one deliverable, and that deliverable can be accepted on its own.
2. Every sub-task carries a written contract, with its input, its output, and its failure handling settled.
3. The dependency drawing has been made, it contains no cycle, and nothing waits on a piece that nobody owns.
4. The handoffs are fewer than the work; if most of the expected time goes to passing messages, waiting, and aligning definitions, pieces get merged back before the run, not after the failure.
5. Every delivery is checked against its contract before it flows downstream, and a failed piece is rerun alone, never the whole graph.

Put it to work