“Use more agents” has become a tempting answer to slow or unreliable agent workflows. It is sometimes right. It is also a costly way to hide an unclear task.
Parallel agents do not automatically create a better result. They create more search paths, context windows, tool calls, and merge work. That can be useful for an open-ended research task and counterproductive for a coding task with one fragile working tree, one unresolved design decision, and a tightly coupled sequence of edits.
Treat parallelism as a search strategy: use it when independent evidence can be gathered and merged, not merely because work can be divided into several labels.
Anthropic's account of its multi-agent research system describes breadth-first investigation in which several agents pursue separate directions and return findings to a lead agent. The article also reports cost and coordination tradeoffs for work with strong dependencies or shared context. Its evaluation results concern Anthropic’s models, harness, and research workload; they are not a cross-vendor benchmark or evidence that more agents improve every task. Teams should validate the pattern with their own models, tools, latency constraints, and evaluation set.
Anthropic’s broader agent-building guidance likewise presents parallelization as useful when subtasks are independent or when several perspectives increase confidence. These vendor accounts motivate the editorial framework below, but they do not establish a universal decision rule.
The useful design question is therefore not “How many subagents should we launch?” It is “What kind of uncertainty does this task have?”
A proposed five-question parallelism map
Virillio Code Editorial proposes five questions as a preflight heuristic. The map is not an industry standard, a validated scoring instrument, or a substitute for workload-specific evaluation.
- Question: Are there independent evidence paths? — Strong signal to parallelize: Several sources, hypotheses, repositories, or user constraints can be investigated separately — Signal to stay sequential: Every step depends on the outcome of the previous one
- Question: Can workers operate in isolation? — Strong signal to parallelize: Read-only research, separate sandboxes, or disjoint resources — Signal to stay sequential: Shared mutable state, one environment, or one approval authority
- Question: Can each worker return bounded evidence? — Strong signal to parallelize: A concise finding, artifact, or ranked set of alternatives can be handed back — Signal to stay sequential: The lead needs the whole transcript or every intermediate decision
- Question: Is there a clear merge rule? — Strong signal to parallelize: Findings can be deduplicated, compared, or combined against explicit criteria — Signal to stay sequential: The result needs continuous joint reasoning or a single evolving plan
- Question: Is the added cost justified? — Strong signal to parallelize: The task is high-value, open-ended, or time-sensitive enough to pay for extra work — Signal to stay sequential: A focused single agent can finish safely with less context and coordination
When the left column dominates, parallelism may be worth testing. When the right column dominates, a single agent with clearer context and an explicit checkpoint is often the simpler baseline.
This is not a purity test. A workflow can start sequentially, split for independent investigation, then return to one lead for synthesis. In fact, that is often the most reliable form of multi-agent work.
Good fits: breadth, alternatives, and independent evidence
Parallel agents are often best suited to tasks with a natural fan-out and a compressible fan-in.
Breadth-first research
Suppose the question is, “What are the most relevant implementation options across several ecosystems?” Each worker can investigate one ecosystem, use the same evidence standard, and return a short findings packet with citations and uncertainty. A lead can then compare the packets.
This is the shape Anthropic describes for multi-agent research: independent exploration reduces path dependence, and each worker compresses a portion of the search space before synthesis.
Independent review lenses
A design proposal can be reviewed in parallel for API compatibility, migration risk, security policy, and developer experience, provided the reviewers are asked to produce bounded observations rather than competing rewrites of the same plan.
The point is not to create a committee. It is to get distinct evidence that one agent would have had to obtain sequentially.
Explicit candidate generation
When a task needs several independent approaches—debug hypotheses, test cases, architecture alternatives, or search queries—parallel work can improve coverage. The merge rule must be set in advance: select the candidate with the strongest evidence, retain a diverse shortlist, or run a small validation against each.
Without that rule, parallelism yields a pile of plausible text rather than a decision.
Bad fits: shared state, tight coupling, and invisible merge work
Some tasks look divisible but are not.
One shared mutable environment
Multiple agents editing the same files, issue, database record, browser session, or deployment at once can create a coordination problem harder than the original task. Separate worktrees, isolated sandboxes, or an explicit ownership partition may make the task parallelizable. LangGraph’s subgraph documentation provides one concrete example of how persistence and per-thread state choices interact with parallel subagent calls; other runtimes may impose different constraints.
One critical path
If agent B cannot act until agent A decides a data model, chooses a dependency, or discovers the cause of a failure, launching both agents early does not shorten the critical path. It merely creates speculative work that may be invalidated.
Use a checkpoint instead: let the lead make or request the blocking decision, then fan out only after the constraint is fixed.
Outputs that cannot be compressed honestly
Parallel workers need a contract for returning information. If every worker's full chain of reasoning, tool transcript, and unfiltered context must be placed into the lead's prompt, the system has not solved the context problem. It has multiplied it.
Ask workers to return a bounded package:
- claim or recommendation,
- supporting evidence or artifact references,
- assumptions,
- uncertainty,
- suggested next action.
The lead can request more evidence on demand. This preserves provenance without turning synthesis into transcript ingestion.
A practical three-phase orchestration pattern
For many tasks, the right architecture is not “many autonomous agents” but a three-phase loop:
- Frame: One lead identifies the goal, constraints, evidence standard, and merge rule.
- Fan out: Workers investigate independent slices in isolated scopes with a bounded return format.
- Synthesize: One lead reconciles contradictions, checks sources, makes the final decision or asks the user for the missing authority.
Each phase has a different job. The lead owns coherence and user intent. Workers own a deliberately narrow search space. The synthesis step owns the judgment that cannot safely be parallelized.
This also clarifies memory. Workers usually need only the task slice, relevant constraints, and enough context to interpret their evidence. They do not automatically need the entire lead-agent history or another worker's scratchpad. Give them the narrowest memory scope that makes the assignment reliable, then make the handoff explicit.
Treat the merge as a product surface
Some consequential multi-agent failures happen after useful work has already been done: a system receives several findings but lacks a rule for resolving disagreement, deduplicating evidence, or communicating uncertainty to the user.
Define the merge contract before launch:
- Merge element: Common question — Example: “Which approach satisfies the migration constraints?”
- Merge element: Evidence requirement — Example: Primary documentation, reproduced test, or directly observed artifact
- Merge element: Output schema — Example: Claim, evidence, uncertainty, and next action
- Merge element: Conflict rule — Example: Prefer directly verified evidence; retain unresolved disagreement
- Merge element: Side-effect authority — Example: Workers may observe and draft; only the lead may request or perform a change
This is the multi-agent equivalent of a function signature. It tells each worker what will be accepted and lets the lead distinguish useful results from verbose activity.
Cost is a design input, not an afterthought
Parallelism spends more than tokens. It consumes orchestration code, tool quotas, latency budget, log volume, and reviewer attention. It can also make a user interaction feel less coherent if several workers are acting on ambiguous intent.
Set a task-value threshold before launching a fan-out. High-value work may justify more search capacity because a missed fact or slow answer is expensive. Routine, well-bounded work may be served more efficiently by a focused single-agent loop.
The threshold can be explicit:
- Use parallel work for independent, high-stakes research or review.
- Use one agent for a narrow edit, a single known lookup, or a task with one dominant dependency.
- Use staged fan-out after a sequential framing step when the task contains both kinds of work.
This prevents a multi-agent system from becoming an automatic tax on every request.
A simple preflight checklist
Before launching subagents, ask:
- What can each worker discover that another worker does not need to discover first?
- What resource, if any, would two workers mutate at the same time?
- What is the maximum useful size of one worker's return package?
- Who decides when workers disagree?
- Is the value of additional coverage greater than the cost of coordination?
If these questions do not have crisp answers, the next improvement is probably better task framing, not another agent.
What we are learning building Virillio Code
Virillio Code's multi-agent and session coordination work is in development. Our current design premise is that concurrency alone does not define a durable handoff, a memory boundary, or a merge policy; the proposed workflow makes those choices explicit. It is not a claim about completed product behavior.
A selective design can fan out when a task has independent search paths, preserve clear ownership where side effects matter, and return to one accountable synthesis step when findings must be reconciled.
Sources and further reading
- How we built our multi-agent research system — Parallel workers are particularly useful for independent, breadth-first research paths but introduce coordination and cost tradeoffs.
- Building effective agents — Parallelization is useful when subtasks are independent for speed or when multiple perspectives increase confidence.
- LangGraph subgraphs — Subgraph state and persistence choices affect isolation and parallel execution tradeoffs.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.