How many agents should run in parallel?

Parallel agents promise a simple trade: spend more compute to finish sooner. In practice, agents may search the same files, implement incompatible solutions, overwrite shared state, and hand a human five plausible answers to reconcile.

The right level of concurrency is an empirical property of the task and orchestrator.

Identify work that can actually be parallelized

Break the workflow into units and map dependencies. Independent research queries, isolated repository modules, or alternative candidate solutions may parallelize well. A tightly coupled migration with one shared schema may not.

For each unit, specify inputs, owned artifacts, completion evidence, and merge contract. If two agents can change the same surface, define how conflicts are detected and resolved before increasing concurrency.

Run a concurrency sweep

Evaluate the same task set with one, two, four, and eight agents—or smaller limits appropriate to your system. Pin the model, harness, environment, budgets, and orchestrator. Repeat stochastic tasks.

Measure:

• verified task success;
• wall time and time to first useful result;
• total tokens, tool calls, and cost;
• duplicate reads, searches, and edits;
• conflicting artifacts and merge failures;
• coordinator time and context growth;
• human review and reconciliation effort.

Plot quality-adjusted completion against both wall time and total cost. A four-agent run that finishes twice as fast at six times the cost may still be correct for an incident and wrong for routine backlog work.

Trace coordination explicitly

Use one parent trace for the task, one branch for each worker, and spans for task assignment, communication, shared-state access, merge, verification, and retry. Record which agent produced each artifact and which evidence the coordinator used to accept it.

This reveals whether parallelism created genuine coverage or repeated the same work. It also exposes a common bottleneck: workers finish quickly while a single coordinator spends most of the runtime reading and reconciling their output.

Our guide to building and evaluating multi-agent applications covers general multi-agent evaluation. A concurrency sweep adds the scaling dimension needed for capacity decisions.

Test shared-state failures

Inject races and partial failures. Delay one worker, return stale state to another, terminate the coordinator, and make two agents edit the same artifact. Verify that the system detects version conflicts, avoids duplicated side effects, and can resume without losing ownership information.

Isolation can improve reliability but raises merge cost. Shared workspaces reduce copying but increase interference. Evaluate the exact strategy you intend to run, not an abstract multi-agent architecture.

Evaluate diversity, not agent count

Multiple identical agents often produce correlated answers. If the goal is search or candidate generation, compare deliberate diversity strategies: different subtasks, context slices, tools, models, or hypotheses.

Measure marginal coverage: what new evidence or solution did each additional worker contribute? Stop adding agents when marginal value falls below marginal cost and coordination risk.

Set concurrency by task class

The result should be a policy, not one universal number. Routine single-file fixes may default to one agent. Broad research might use several independent workers. High-risk changes may use parallel proposal generation but one controlled executor.

Monitor production curves because repositories, tools, and models change. Keep a budget cap and degrade gracefully when workers or providers are unavailable.