Multiple agents can inspect different parts of a problem, implement independent changes, or challenge one another’s work. Parallelism is useful only when the work can be decomposed without creating more integration cost than execution value.
Decompose by stable boundaries
Good parallel tasks have clear inputs, outputs, and limited overlap. Examples include independent research, test design, documentation, or changes behind stable interfaces. Two agents editing the same assumptions in different files can create semantic conflict even when Git merges cleanly.
The coordinator should identify shared decisions before work begins.
Give each agent a contract
Every agent needs a bounded objective, authoritative context, permitted files or systems, expected evidence, and a completion signal. Roles such as implementer, reviewer, security analyst, or investigator are useful only when their responsibilities are concrete.
Role labels should not substitute for task boundaries.
Isolate and integrate deliberately
Separate branches or worktrees protect concurrent changes. Integration should follow a known order when outputs depend on one another. A coordinator compares assumptions, resolves interface changes, and runs checks against the combined result.
Passing individual tests does not prove that the integrated system is coherent.
Use disagreement as evidence
Independent agents can surface conflicting interpretations of the same requirement. That disagreement is valuable because it identifies ambiguity. The human should resolve the underlying decision, then update the shared context.
A majority vote between models is not accountable authorization.
Split the work after agreeing on the interface
The fictional Northstar case offers three possible tasks: implement server deduplication, prepare client contract tests, and challenge the transaction design. All three depend on ADR-17. Running them before key scope and retention are agreed multiplies incompatible assumptions.
| Assignment | Input | Output | Integration condition |
|---|---|---|---|
| Server implementation | Accepted ADR and sandbox schema | Patch plus evidence | Does not modify client contract. |
| Client verification | Same accepted ADR | Retry and conflict cases | Uses the server’s agreed response semantics. |
| Independent challenge | Contract and proposed design | Counterexamples and unresolved assumptions | Cannot silently change the acceptance standard. |
The coordinator owns the combined result. That role can be a person or a bounded orchestration system, but consequential decisions still have named human authority.
Clean merges can contain incompatible software
Imagine one agent scopes the key globally while another assumes it is account-scoped. They edit different files. Git has nothing to complain about. The system can still disclose an inappropriate stored response or reject a legitimate request.
Integrate against contract tests, not merely a merge result. Run the combined revision and preserve which task produced each change. If a shared assumption changes, invalidate the dependent work explicitly and tell every affected task.
Isolated worktrees reduce accidental file interference; they do not isolate database side effects or external services. Use separate test resources or a controlled integration environment as well.
Independence is not a role name
Two agents given the same mistaken specification may enthusiastically agree. A reviewer prompt does not create an independent oracle. Give the challenge task explicit failure classes, separately established acceptance cases, and permission to report that the specification itself is insufficient.
The compiler experiment reported by Anthropic illustrates both parallel progress and coordination limits: shared bottlenecks required changes to the test harness, and the resulting compiler retained material limitations. Treat it as evidence about one bounded experiment, not a staffing ratio for your organization.
Decide whether parallelism earned its cost
Record elapsed time, total effort, compute cost, integration work, and rework. Compare a suitable task with a single-agent path. Parallel execution can shorten the calendar while increasing total cost; that may be worthwhile, but it is a decision to make explicitly.
Do not split a tightly coupled change just to use available agents. Start with one independent challenge or test-design task. Expand when the boundaries and evidence show that concurrency helps.