Answer
When should multiple agents work in parallel?
When the pieces are independent, each reads a lot, and the results can be integrated without anyone choosing between them.
When the pieces do not depend on each other, each reads far more than it reports, and combining the results is mechanical. If integration requires deciding between outputs, running in sequence is usually faster overall.
The first condition is genuine independence, which is stricter than it sounds. Two pieces are independent if either could be done first without changing the other. Pieces where the second would be informed by the first are a sequence, and running them together means the second is done from an assumption about what the first will find. The time saved is then spent reconciling, usually at a worse rate.
The second is that each piece reads a lot and reports a little. This is the same criterion that justifies any delegation, and it matters more in parallel because the total intake across runs is large. Several runs each consuming a modest amount and returning a modest amount is an expensive way to arrive at what one run could have held.
The third is that integration is mechanical. Findings that concatenate — here is what each area contains, here is the value in each region, here is which of these files matches — combine without judgement. Findings that overlap or conflict require someone to decide, and that decision is the work, so the parallelism has moved effort rather than removed it.
There is a fourth condition that is easy to overlook and usually binding: the results have to be absorbable. Producing six findings simultaneously is only useful if six findings can be read and acted on, and in most settings the reviewing capacity is the constraint rather than the generating capacity. Parallelism that outruns absorption produces a queue and the illusion of throughput.
The failure to avoid is parallelising a sequence because the pieces have names. A plan, an implementation and a set of tests are three activities and one chain: the implementation depends on the plan and the tests depend on the implementation. Running them together produces three artefacts that do not fit, and the fitting is more work than doing them in order would have been.
Where all four conditions hold, the arrangement is genuinely good and worth setting up properly: partitioned inputs, self-contained briefs, evidence in the returned results, and a defined place the results land. Where they do not, one run doing the work in order is simpler, cheaper to debug and usually finishes sooner in wall-clock terms once reconciliation is counted.
Parallelism pays where the results add up, and costs where somebody has to decide which of them was right.
Siddharth Sharma, Context Theory
Related questions
Is parallel work faster in practice?
In wall-clock terms for genuinely independent pieces, yes. Once integration and reconciliation are counted, the advantage narrows considerably and reverses where the pieces were not really independent. The honest comparison includes the time spent making the outputs fit, which is the part omitted from most estimates.
How do you test whether pieces are really independent?
Ask whether either could be done first. If one order is obviously better, there is a dependency, and running them together means the later piece proceeds on an assumption. This test takes seconds and disposes of most proposed parallel divisions, which is why it is worth applying before rather than after.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Odds of qualifying a lead — replying within the first hour vs after it | 7× | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Independence means either piece could be performed first without altering the other, so a pair with a preferred order is a sequence, and running it in parallel makes the later piece proceed from an assumption about the earlier one's result. | Asking whether either candidate piece could be completed first without changing the other. |
| Response | Parallelism pays only where integration is mechanical, because findings that overlap or conflict require a decision, and that decision is the work the arrangement was meant to distribute. | Examining whether the returned results can be concatenated or must be chosen between. |
| Buying behaviour | Absorption capacity rather than generation capacity is usually the binding constraint, so parallelism exceeding what can be read and acted on produces a queue and the appearance of throughput. | Comparing results produced per period against results acted on in the same period. |
| Software | Naming three activities does not make them independent: a plan, an implementation and tests form a chain, and running them together yields artefacts that must be fitted at greater cost than doing them in order. | Attempting to write tests against an implementation that does not yet exist and comparing the rework required. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one