Answer
How do you prevent subagents from duplicating each other's work?
Partition the work rather than describing it. Overlapping briefs are both answered in full, and neither run knows the other exists.
Partition by input rather than by topic. Two briefs describing overlapping subjects will each be answered completely, because neither run can see the other. Naming which files, records or ranges each covers removes the overlap by construction.
The framing of the question implies a coordination problem, and there is nothing to coordinate: delegated runs cannot see each other, cannot negotiate, and have no way to discover that a sibling is covering the same ground. Whatever overlap exists in the briefs will appear in full in the results. The only place duplication can be prevented is in how the work was divided.
The reliable division is by input rather than by subject. Give one run these files and another those, one run this date range and another that, one run these record identifiers and another those. Each brief then defines a set that cannot overlap, and the union is checkable: you can confirm that every item is covered exactly once before anything runs.
Division by topic fails because topics do not have edges. Investigate how errors are handled and investigate how retries work will both read the same code, reach overlapping conclusions, and return them with different emphasis. Nothing was misunderstood; the two subjects genuinely overlap, and the overlap was created when the briefs were written.
Where the work genuinely cannot be partitioned by input — a search where you do not know in advance where the answer lives — the honest answer is that parallel delegation is the wrong shape. One run searching is cheaper than three runs searching the same places, and the appearance of parallelism is buying nothing. Speculative fan-out is occasionally justified and should be a deliberate choice rather than a side effect of dividing an unpartitionable job.
There is a second kind of duplication worth naming: two runs producing the same artefact rather than the same finding. Each writes a helper, a summary, a section, and both are correct. This is not preventable by partitioning inputs, because both were entitled to produce output. It is prevented by deciding in advance who owns each output, which is a different statement from who reads which input.
Finally, check the union rather than trusting it. Before dispatching, list what each brief covers and confirm the coverage is complete and disjoint. This takes a minute, it catches the overlap that is obvious in hindsight, and it also catches the gap — the part of the work no brief covered, which is the failure that nobody notices because every run reports success.
Delegated runs cannot coordinate, so the coordination has to happen in the briefs before either of them starts.
Siddharth Sharma, Context Theory
Related questions
Can you tell a subagent what the others are doing?
You can, and it helps less than it should. The information arrives as a description rather than as a constraint, and a run that encounters something relevant will report it regardless of having been told a sibling covers it. Treat it as a hint that reduces emphasis, not as a partition, and do the actual partitioning in the inputs.
What if two runs return contradictory findings about the same thing?
That is information rather than a failure, and it usually means the thing is genuinely ambiguous or that the two looked at different instances of it. Reconciling requires going back to what each read, which is why per-claim references matter: without them the contradiction cannot be resolved and one answer gets chosen arbitrarily.
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 |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Delegated runs cannot observe or negotiate with one another, so any overlap present in the briefs appears in full in the results and the only point of prevention is the division of work itself. | Dispatching two overlapping briefs and comparing the returned results for shared conclusions. |
| Software | Partitioning by input — named files, record identifiers, date ranges — creates sets that cannot overlap and whose union is checkable before dispatch, while partitioning by topic fails because topics have no edges. | Listing the inputs each brief covers and testing whether the sets intersect. |
| Response | Work that cannot be partitioned by input is the wrong shape for parallel delegation, because several runs searching the same unknown territory cost more than one and produce the same answer. | Comparing total cost of a single search run against several parallel runs on the same open question. |
| Constraint | Checking the union of briefs before dispatch catches the uncovered portion as well as the overlap, and the gap is the more damaging failure because every run reports success on what it was given. | Comparing the union of dispatched briefs against the full scope of the task. |
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