Use one agent when the task requires a continuous understanding of shared state or frequent decisions across the same files. Consider several agents when the work separates into independently useful outputs with clear ownership and a manageable integration step.
The relevant unit is not a file count or the number of available agents. It is a dependency: what does one worker need to know before its work can be correct?
A ten-file change can be tightly coupled. A research question about three independent components can be naturally parallel. More agents only help if the work they perform in parallel outweighs the work needed to brief, coordinate, verify, and combine them.
Draw the dependencies before assigning roles
Imagine adding a new status field to a service. The database representation, API response, client behavior, and migration plan all depend on what the field means. Assigning one agent to each layer before defining that meaning creates parallel activity around an unresolved decision.
A better first step is to agree on the contract: allowed values, transitions, compatibility, and treatment of existing records. After that, some work may become independent. One worker could inspect consumer compatibility while another prepares tests against the settled contract.
For each proposed subtask, record its input, output, owner, and dependencies. Then ask whether the output will remain useful if another worker finishes later or proposes a different implementation.
| Work | Dependency structure | Reasonable starting design |
|---|---|---|
| Reproduce and fix one bug spanning parser and caller | Findings repeatedly change the next step | One implementation agent |
| Compare three documented storage options | Independent source collection, shared evaluation criteria | Parallel research with one synthesis owner |
| Implement client and server before agreeing on a payload | Both depend on an unresolved contract | Settle the contract first |
| Review an already frozen patch from two perspectives | Shared stable input, separate findings | Independent read-only review |
| Rename a symbol mechanically across a repository | Explicit transformation, little interpretation | Existing refactoring tool or script |
This is a proposed architectural decision table. It does not establish a speedup for any model or repository.
Separate useful parallel work from duplicate work
Two workers reading the same subsystem are not necessarily wasting effort. Independent investigation can reveal different failure modes. But the reason for duplication should be explicit.
If the goal is coverage, give each reviewer a distinct question: one traces backward compatibility, another checks authorization. If the goal is independent judgment, give both the same stable evidence without feeding one the other's conclusion first.
Agreement is still not proof. Agents using the same model, prompt, and incomplete source can repeat the same error. A second review is useful when it produces independently checkable evidence, not just a second confident sentence.
Anthropic's workflow patterns distinguish parallel sectioning from multiple attempts at the same task. Those are different uses of additional calls. Decide which you need before treating every extra worker as a productivity improvement.
A worked design: auditing three adapters
Suppose a repository has adapters for three external services. The task is to identify whether each adapter preserves cancellation and reports partial failure accurately. No implementation changes are authorized yet.
This work has a natural common rubric and separate bodies of evidence. Assign one adapter to each worker. Require each report to contain:
- The adapter revision and relevant entry points.
- The path taken when cancellation arrives.
- The source and meaning of the returned status.
- One concrete failure scenario, with code locations.
- What was inspected, what was executed, and what remains uncertain.
One coordinator owns the combined conclusion. It checks whether each report uses the same definition of cancellation and whether shared infrastructure changes the interpretation. For example, three adapters may call one wrapper that swallows cancellation. That shared finding is a reason to revise the decomposition, not to keep producing three disconnected reports.
The coordinator should preserve the underlying references when compressing findings. “All adapters are safe” is not a useful handoff if the source reports actually mean “no defect found in these paths, without an integration test.”
This is a documentary design example. No three-agent audit or timing comparison was run for this article.
Shared state makes coordination expensive
File separation helps, but it is not the entire state boundary. Workers may share a database, package lockfile, generated output, test port, container, or external account. They can interfere without editing the same source file.
Git's worktree documentation describes separate working trees attached to one repository. That can separate working files and indexes. It does not isolate network services, databases, credentials, or every piece of repository metadata.
For parallel editing, define exclusive file ownership where possible, choose one integration owner, and state how shared artifacts are updated. Two agents should not regenerate the same lockfile independently and leave the reviewer to infer which dependency graph was intended.
When work must touch the same area, a sequential handoff may be simpler: one agent completes a bounded change, records the resulting revision and checks, and the next starts from that state. A merge conflict is only the visible subset of integration problems; logically incompatible changes can merge cleanly.
Keep delegation smaller than the task
A useful assignment gives the worker enough context to act while making the boundary clear:
Inspect cancellation in adapter B at the supplied revision. Do not edit files. Return the relevant call path, any finding with a concrete failure condition, and the checks you ran. If the conclusion depends on the shared request wrapper, identify that dependency instead of changing it.
The coordinator needs a stopping rule too. If all workers keep asking each other for broad context, the task may not be separable. If every report needs substantial reconstruction, the requested output is probably too vague.
Anthropic's account of its multi-agent research system discusses delegation and coordination costs in a research setting. It also identifies tightly dependent coding work as a poor fit for some forms of parallelization. Its reported results concern its own system and evaluation; they do not predict the outcome of the adapter example or a different coding workflow.
Measure accepted work, including integration
If parallelism matters enough to adopt, compare it on representative tasks. Record time to a verified, accepted result, total available usage, human intervention, integration defects, and work discarded as duplicate or out of scope.
Hold the task and acceptance criteria constant. A multi-agent run with more total budget answers a different question from a comparison at a fixed budget. Both may be useful, but label them.
Include the coordinator's effort. Finishing three branches quickly is not a success if combining them takes longer than doing the change once. Likewise, a single agent's shorter transcript is not proof that it produced better work.
Begin with one accountable owner. Add workers for a specific reason: independent investigation, separate implementation surfaces, or an evidence-based review question. Keep the arrangement only if the resulting work is easier to verify and use.
Research note: sources reviewed October 28, 2026. This article compares workflow structures; it reports no measured multi-agent speedup, reliability gain, or token savings.
