Task decomposition
Choose when to delegate independent work and define handoffs, shared-state rules and evaluation.
THE IDEA
Task decomposition
Delegating to several agents only pays off if the work really splits. Look at outputs and dependencies. Three research tasks of 2, 5 and 3 minutes are independent, and merging them takes 1 more minute and needs all three. One worker needs 11 minutes; one worker per task needs 6, because the merge waits for the slowest. Dependent steps, such as editing what another step produces, need an order and a contract about what is handed over.
Split work by outputs and dependencies. Independent research can run at the same time; dependent steps need an order and a contract about what the earlier step hands over.
Predict first. Can task B safely consume an unfinished artifact from task A without a contract?
Chapter context
Delegation can divide a task into focused work units, but coordination creates costs and new failure paths. Add helpers when their independent contributions can be integrated and checked more clearly than one agent can do the work alone.
TRY IT YOURSELF
Part 1. Do it hands-on
Time the plan by hand, then write the scheduler that respects dependencies.
Split work by outputs and dependencies. Independent research can run at the same time; dependent steps need an order and a contract about what the earlier step hands over.
- To do: Three independent research tasks take 2, 5 and 3 minutes; merging their results takes 1 minute and needs all three. One worker doing everything in turn takes how many minutes?
- To do: With one worker per research task (they overlap), the merge starts when the slowest finishes. Total minutes?
- To do: Speed-up (sequential time / parallel time, 3 decimals)?
- To do: Can task B safely consume an unfinished artifact from task A without a contract? Type yes or no
Part 2. Do it in code
- jobs is a dict {id: {"dur": minutes, "deps": [ids]}}.
- topo_order(jobs): the ids in a valid order (dependencies first; among ready jobs, sorted by id). ValueError for a cycle or an unknown dependency.
- sequential_time(jobs): the sum of durations.
- finish_times(jobs): {id: finish} with unlimited workers: finish = dur + the latest finish among its dependencies.
- parallel_time(jobs): the latest finish time (0 for no jobs).
- speedup(jobs): sequential_time / parallel_time (1 if there are no jobs).
- ready(jobs, done): the sorted ids not in done whose dependencies are all in done.
Stuck, or something not working? You can come back to it any time.
CHECK YOUR UNDERSTANDING
Can task B safely consume an unfinished artifact from task A without a contract?
Chapter reference: math, worked example & code
This section belongs to the whole chapter, so it is the same on every lesson in it and may cover a different lesson's topic. The code for the experiment you just ran is inside the experiment itself.
Math and notation
With independent parallel task durations and merge time m, an ideal lower-bound schedule is , excluding orchestration overhead. If independent tasks each succeed with probability p, all n succeed with probability ; correlated failures invalidate that simple model.
Worked example
Three tasks take 2,5 and 3 minutes; integration takes 1. Ideal sequential duration is 11 minutes, while fully independent parallel duration is 6. Separately, three independent 90%-reliable components all succeed with probability 0.9^3=0.729. The latency gain does not itself establish a reliability gain.
Reference code
The following example uses the Python standard library and does not call a remote service.
from math import isclose
times,merge=[2,5,3],1
assert sum(times)+merge == 11
assert max(times)+merge == 6
assert isclose(.9**3,.729)
Python examples are provided for study and local execution; this page does not execute Python.
Common mistakes
Parallel workers need explicit ownership of shared artifacts. Agreement can reflect correlated failure. More agents can increase token usage and integration work even when wall-clock time falls.