Choosing the Limit From the Work

The limit should follow the work rather than a fear of what the work might become. Set it too low and tasks fail because a helper that genuinely needed to break its job down was not allowed to. Set it too high and the run pays for fan-out nobody intended. The right starting point is the smallest number that lets one real decomposition succeed, raised only when a concrete task actually needs the extra level.

The two failure directions have different tells. An over-tight limit shows up as helpers that return skeleton answers, summaries of what should be done rather than evidence that it was done. An over-loose limit shows up as a run whose breadth is hard to explain, with cost and latency rising faster than the size of the task. Watching for either signal is more reliable than guessing a number once and leaving it.

It also helps to separate the kinds of work. A task that reads and summarises rarely needs deep delegation, because a single helper can do it in one pass. A task that genuinely partitions, such as checking a list of independent items, may need exactly one more level and no further. Matching the limit to the work keeps the bound meaningful instead of arbitrary.

The closing idea is that a bound is a design statement. Saying that a run may be two levels deep is saying how much of the job should be spread out and how much should stay in one place. That is a decision worth making on purpose, and it is far cheaper to make than to discover.