---
title: Swarms Multiply Errors
slug: swarms-multiply-errors
canonical_url: https://blog.openfactoryai.com/swarms-multiply-errors
published_at: 2026-07-14T20:59:00.289665+00:00
author: OpenFactoryAI
tags: multi-agent systems, AI swarms, agent orchestration, parallel agents, software automation
tldr: Adding agents multiplies candidates and specialization. It also multiplies messages, stale views, duplicated work, correlated mistakes, tool conflicts, and verification load. A swarm earns its cost only when work can be isolated, agents contribute genuinely different information, and one controlled merge path converts candidates into a verified outcome. Start with one agent, add parallel branches for measured bottlenecks, and never let consensus substitute for evidence.
key_takeaways:
  - More agents create candidate coverage, not guaranteed correctness.
  - Shared models, prompts, context, and sources create correlated failure that voting cannot wash away.
  - Full-mesh communication grows quadratically and fills context with duplicated state.
  - Parallel mutation must remain isolated until an authorized verifier selects and rechecks one artifact.
  - Scale agent count only while marginal verified-outcome value exceeds inference, coordination, verification, and risk cost.
---

One agent can be wrong once.

Ten agents can agree on it.

Agreement feels like confidence because human teams use independent perspectives to correct error. A swarm of agents may share the same model, system prompt, retrieved document, tool wrapper, and blind spot. Ten copies can produce ten correlated versions of one mistake.

The case for swarms is not consensus. It is controlled diversity: parallel search, specialized evidence, independent verification, and faster completion of work that truly decomposes.

::figure{template=branch caption="A safe swarm isolates candidates and admits exactly one verified merge" items="Parent task :: fixed goal, state, budget | Branch A :: implementation candidate | Branch B :: alternative candidate | Branch C :: evidence and risk review | Verifier :: same tests, policy, outcome rubric | Selector :: choose, combine, or reject | Merge :: recheck base revision and postconditions | Cancel :: stop and dispose losing work"}

## A swarm is a distributed system with probabilistic workers

Once multiple agents act concurrently, familiar distributed-systems questions appear:

- who owns current task state?
- which revision did each agent observe?
- are messages ordered, duplicated, or lost?
- can two agents mutate the same object?
- how are leases and budgets divided?
- which result is authoritative?
- how does a losing branch stop?
- what happens if the coordinator dies?

Natural-language conversation does not answer them. It is payload, not consistency protocol.

[AutoGen](https://arxiv.org/abs/2308.08155) presents a framework for building applications through conversations among configurable agents. [CAMEL](https://papers.neurips.cc/paper_files/paper/2023/hash/a3621ee907def47c1b952ade25c67698-Abstract-Conference.html) studies role-playing communicative agents. [ChatDev](https://aclanthology.org/2024.acl-long.810/) organizes specialized agents and communication for software development. These works establish useful orchestration patterns and reported experimental systems. They do not establish that adding agents universally improves production outcomes.

The runtime still needs durable state, typed tools, authority, traces, and verification.

## There are four distinct reasons to add an agent

1. **Parallel search:** generate diverse candidate solutions or plans.
2. **Functional specialization:** use different tools, models, contexts, or verifiers for different subproblems.
3. **Independent challenge:** try to falsify evidence or a candidate under a separate context.
4. **Latency decomposition:** execute independent critical-path work concurrently.

“Give it a persona” is not automatically specialization. Two roles using the same evidence and action space may produce stylistic diversity without information diversity.

For each new agent, state the marginal capability:

```text
new observation?
new tool or authority?
new model or training?
new search seed or strategy?
new verifier?
independent failure mode?
parallelizable critical-path work?
```

If all answers are no, the extra agent is probably another sample. Treat and price it as inference-time sampling, not an organization chart.

::figure{template=matrix caption="Agent roles create value only through differentiated information or control" items="Explorer :: broad search / no mutation | Specialist :: unique tool or domain evidence | Builder :: isolated candidate mutation | Critic :: falsification and risk | Verifier :: independent executable proof | Coordinator :: state, budget, merge, stop"}

## Communication edges grow faster than agents

In a full directed mesh, `n` agents can send to `n - 1` others:

```text
directed communication edges = n(n - 1)
```

| Agents | Directed edges |
|---:|---:|
| 2 | 2 |
| 4 | 12 |
| 8 | 56 |
| 16 | 240 |

This does not mean every swarm emits on every edge. It shows why unrestricted group chat scales badly. Messages repeat history, arrive after state changes, and consume context in every recipient.

Use topology deliberately:

- **star:** workers report to one coordinator;
- **tree:** subcoordinators aggregate bounded domains;
- **pipeline:** each role owns one typed transition;
- **blackboard:** agents read and append structured artifacts;
- **market or auction:** agents bid for tasks under budgets;
- **full mesh:** reserve for small teams where direct debate is the mechanism being tested.

The blackboard should contain verified state and artifacts, not a shared editable narrative. Messages propose updates; a reducer or coordinator commits accepted state transitions.

::figure{template=bar caption="Directed full-mesh communication edges grow quadratically" items="2 agents :: 2 | 4 agents :: 12 | 8 agents :: 56 | 16 agents :: 240"}

## Consensus only helps against sufficiently independent error

Suppose one classifier has independent correctness probability `p = 0.60`. A five-sample majority succeeds with probability:

```text
C(5,3)(.6)^3(.4)^2 + C(5,4)(.6)^4(.4) + (.6)^5
= 0.68256
```

That improvement depends on independent, identically distributed votes and a binary objectively scored task. Language-agent outputs are rarely independent or directly voteable.

Correlation enters through:

- same base model and training data;
- same prompt and role framing;
- same context assembly and retrieval miss;
- same tool bug or environment;
- agents seeing previous answers before deciding;
- selection by another model with the same blind spot;
- one confident agent anchoring the group.

Measure diversity at the mechanism level:

- different evidence sources and citations;
- different action or dependency graphs;
- different failure modes under tests;
- pairwise candidate similarity;
- error correlation across task slices;
- incremental verifier coverage;
- outcome gain after adding each branch.

Five paraphrases are not five independent attempts.

## Debate can improve or destroy evidence

Debate is useful when one agent presents a falsifiable claim and another has tools or evidence to challenge it. It fails when agents optimize persuasion, repeat unsupported claims, or converge because later turns contain earlier opinions.

Use a structured protocol:

```text
claim
supporting artifact and exact locator
assumptions
counterexample or falsification test
response with new evidence only
verifier decision
```

Blind the first round when independence matters. Each agent inspects the task before seeing other candidates. Reveal claims only after initial evidence is committed. This reduces anchoring and lets the system measure genuine convergence.

Do not ask the group to vote on facts that executable tools can establish. Run the test once in a trusted verifier. Use agents to propose what to test, not to outvote the receipt.

## Parallel writers need isolated worlds

Two agents editing one checkout create races:

```text
A reads revision r0
B reads revision r0
A writes patch a -> r1
B writes patch b against r0 -> overwrites or conflicts with r1
```

Give every candidate branch:

- immutable base revision;
- isolated filesystem, process, and credentials;
- separate idempotency namespace;
- branch budget and deadline;
- artifact hash and provenance;
- no direct authority to merge or deploy.

The selector compares candidates in a clean verifier environment. If it combines patches, the combination is a new candidate that must pass all checks again. Passing branches independently does not prove the merge passes.

State merge is harder than text merge. Two agents may make individually valid assumptions that conflict. Record preconditions and postconditions, not only diffs.

::figure{template=state-machine caption="Parallel mutation stays speculative until one artifact crosses the merge boundary" items="Forked :: same immutable base | Working :: isolated tools and budgets | Candidate :: artifact plus evidence | Verified :: independent checks | Selected :: one or composed candidate | Rebased :: current target revision | Reverified :: checks after composition | Committed :: one authoritative effect"}

## Cancellation is part of swarm economics

Parallelism buys shorter wall time only if losing work stops promptly. A branch can continue consuming tokens, GPU slots, browsers, sandboxes, and verifier capacity after another branch has won.

Track:

```text
time_to_first_verified_candidate
time_to_cancel_signal
time_to_worker_stop
tokens_after_cancel
tools_after_cancel
orphaned_effects
```

Cancellation should propagate through queues, model streams, tool subprocesses, and child agents. An agent may not see a natural-language “please stop” while blocked on a tool. The runtime owns a cancellation token and lease.

Preserve the losing trace long enough to learn whether it contained novel evidence. Dispose of mutable sandboxes and revoke credentials after the retention decision.

## The coordinator can become the slowest agent

A star topology bounds communication, but every result passes through one coordinator. If workers generate candidates faster than the coordinator can inspect, select, and dispatch, the system forms a queue at the control plane.

Let:

```text
worker result arrival rate = λ results/second
coordinator service rate = μ results/second
```

When sustained `λ >= μ`, backlog grows. Adding workers makes time to verified outcome worse even if each worker is fast.

Reduce coordinator work with typed summaries and hierarchical aggregation:

- workers emit candidate metadata, evidence locators, cost, and terminal status in a fixed schema;
- deterministic filters reject invalid or duplicate candidates;
- specialized verifiers run before coordinator review;
- subcoordinators own disjoint task partitions;
- the root sees bounded winners and exception reasons, not every token.

Do not let the model coordinator summarize away receipts. The canonical artifact and verifier results remain addressable by hash.

Track coordinator utilization, queue age, candidates per task, selection latency, and percentage rejected by cheap prefilters. Scale the verification and selection plane with search, not merely the candidate plane.

## Shared memory creates stale confidence

A shared conversation often becomes the swarm's memory. It is convenient and unsafe. Agents can read obsolete plans after the repository changed, repeat a hypothesis that a verifier already rejected, or treat another model's assertion as an observation.

Use a structured blackboard with record types:

```text
fact       externally observed, with artifact and freshness
hypothesis model proposal, never authoritative
candidate  immutable output tied to base state
decision   coordinator or policy result with inputs
receipt    verified external effect
rejection  verifier result and reason
```

Every record has an ID, author, task, state version, creation time, expiry or invalidation rule, and provenance. Agents subscribe to relevant changes rather than replaying the whole board.

Before acting, a worker checks that its lease and base state remain current. A correct action against state version 11 can be unsafe after version 14. The runtime rejects stale mutations and tells the worker whether to rebase, restart, or stop.

## One compromised agent must not become team truth

Multi-agent systems increase the number of inputs that can contain prompt injection, poisoned retrieval, malformed artifacts, or malicious tool results. A message from another agent is untrusted data unless its claim is backed by a trusted receipt.

Threat boundaries include:

- an explorer retrieves instructions embedded in a document;
- a builder places commands in a patch comment;
- a critic fabricates a test result;
- a coordinator forwards secrets to broader context;
- a verifier is asked to inspect an adversarial artifact;
- an external agent requests authority it does not possess.

Controls:

1. label origin and trust class on every message and artifact;
2. separate data from system instructions at each model boundary;
3. validate schemas, sizes, encodings, and content types;
4. run untrusted artifacts in isolated verifiers;
5. derive authority from authenticated runtime identity, never role text;
6. require independent receipts for claims about effects;
7. rate-limit fan-out and recursively spawned agents;
8. preserve quarantine and rejection evidence for investigation.

A role called “Security Reviewer” has no special authority because the prompt says so. It gains access only through policy bound to runtime identity and current task state.

## Verification load is the hidden swarm tax

If `n` agents produce `k` candidates each, naive verification can require `n × k` full test runs. Selection may add pairwise comparison or merge experiments. The swarm can move the bottleneck from inference to CI.

Use a verifier funnel:

```text
schema and artifact integrity
duplicate and near-duplicate detection
focused task checks
static policy and security
full regression for survivors
integration for the selected candidate
post-merge revalidation
```

Cheap filters must be calibrated. A false reject discards useful diversity; a false accept consumes scarce downstream capacity. Preserve filter scores and later outcomes so thresholds can be tuned against cost per verified result.

The selector should be verifier-aware when launching branches. If only two full regression slots remain before the deadline, generating fifty candidates is not useful search.

## Worked economics: eight agents lose to three

Consider 1,000 illustrative tasks. Compare three parallel builders with eight:

| Metric | 3-agent swarm | 8-agent swarm |
|---|---:|---:|
| Verified success | 74% | 79% |
| Inference and tools / task | $3.20 | $7.80 |
| Verification / task | $0.90 | $2.10 |
| Human exceptions | 9% | 15% |
| Minutes per exception | 18 | 26 |

At $60 per human hour:

```text
3-agent run cost = 1,000 × ($3.20 + $0.90) = $4,100
3-agent exception cost = 1,000 × .09 × 18/60 × $60 = $1,620
3-agent total / success = $5,720 / 740 = $7.73

8-agent run cost = 1,000 × ($7.80 + $2.10) = $9,900
8-agent exception cost = 1,000 × .15 × 26/60 × $60 = $3,900
8-agent total / success = $13,800 / 790 = $17.47
```

The eight-agent swarm buys 50 additional successes for $8,080 additional total cost:

```text
marginal cost per added success = $8,080 / 50 = $161.60
```

If an added verified outcome is worth more than $161.60 after latency and risk, expansion may still be rational. For ordinary tasks, the three-agent policy wins.

::figure{template=compare caption="Illustrative swarms trade outcome coverage against coordination economics" items="3 agents :: 74% success, $7.73 per success | 8 agents :: 79% success, $17.47 per success | Increment :: 5 points cost $161.60 each"}

## Route swarm size by task difficulty

Do not run eight agents for every task. Begin with one bounded agent. Escalate when evidence says the task is hard:

- low localization confidence;
- conflicting evidence;
- failed first candidate with a localized reason;
- high outcome value that justifies search;
- decomposable independent subproblems;
- strong verifier that can select candidates;
- remaining deadline and capacity.

Use a stopping frontier:

```text
add another branch when
P(new branch changes verified outcome) × outcome value
> branch inference + tools + verification + queue + risk
```

This is TokenMaxing applied to agent count.

## Swarms need one authority graph

Specialization should not imply blanket permission. Give each role the minimum capability:

| Role | Reads | Writes | Decides |
|---|---|---|---|
| Explorer | evidence and task state | proposed evidence artifact | no mutation |
| Builder | approved evidence, isolated repo | sandbox candidate | no merge |
| Critic | candidates and receipts | critique artifact | no candidate edit |
| Verifier | candidate, hidden checks | verification receipt | pass/reject only |
| Coordinator | task state and all receipts | state transitions | branch, cancel, select |
| Committer | selected verified artifact | target effect | commit under policy |

No conversational majority grants production authority. The committer checks current policy, target revision, terminal evidence, and idempotency at execution time.

## Train teams on coordination failures

Evaluation should inject:

- delayed and duplicated messages;
- stale branch state;
- one malicious or confidently wrong participant;
- correlated retrieval failure;
- tool outage affecting one specialist;
- coordinator death and lease recovery;
- branch budget exhaustion;
- verifier disagreement;
- merge conflict after selection;
- cancellation that arrives during a tool call.

Score terminal outcome, cost, communication, stale-state actions, duplicate mutation, cancellation waste, and recovery. A swarm that succeeds only under perfect scheduling is a demo with more characters.

## Builder playbook

1. Establish the single-agent and parallel-sampling baseline.
2. Add an agent only for new information, capability, verification, or critical-path parallelism.
3. Use a topology with bounded communication rather than default group chat.
4. Commit individual first-round evidence before agents see each other's answers.
5. Share structured state and artifacts, not one editable narrative.
6. Isolate every mutating branch from production and from other branches.
7. Select with independent evidence, then rebase and reverify one artifact.
8. Propagate cancellation through inference, tools, queues, and child tasks.
9. Measure error correlation and marginal verified-outcome value by agent count.
10. Keep merge and deployment authority outside conversation.

Swarms are not intelligent because they are plural.

They are useful when plural work creates measurable new evidence faster than it creates coordination debt.

## References

- [Wang et al., “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation,” COLM 2024](https://openreview.net/pdf?id=BAakY1hNKS). A configurable framework for multi-agent conversational applications.
- [Li et al., “CAMEL: Communicative Agents for Mind Exploration of Large Scale Language Model Society,” NeurIPS 2023](https://papers.neurips.cc/paper_files/paper/2023/hash/a3621ee907def47c1b952ade25c67698-Abstract-Conference.html). A peer-reviewed communicative role-playing agent framework.
- [Qian et al., “ChatDev: Communicative Agents for Software Development,” ACL 2024](https://aclanthology.org/2024.acl-long.810/). Specialized conversational agents in a staged software-development framework.
- [Wang et al., “More Agents Is All You Need,” 2024 preprint](https://arxiv.org/abs/2402.05120). Sampling-and-voting experiments showing gains under the evaluated tasks and configurations; agent count is not universal production evidence.
- [Foerster et al., “Counterfactual Multi-Agent Policy Gradients,” AAAI 2018](https://ojs.aaai.org/index.php/AAAI/article/view/11794). Counterfactual agent-specific credit under shared team reward.
- [Dean and Ghemawat, “MapReduce,” OSDI 2004](https://www.usenix.org/legacy/events/osdi04/tech/full_papers/dean/dean.pdf). A foundational example of parallel work with explicit partitioning, aggregation, and failure handling rather than unconstrained peer conversation.


## FAQ

### What is an AI agent swarm?

It is a multi-agent system in which several model-driven workers search, specialize, review, coordinate, or act toward one task. A production swarm also needs shared-state, authority, merge, cancellation, and verification semantics.

### Do more AI agents improve accuracy?

They can increase candidate coverage when attempts are diverse and a reliable selector exists. Gains shrink when agents share models, prompts, context, sources, tools, and failure modes.

### How should agents communicate?

Use a topology suited to the work, such as coordinator star, tree, pipeline, or structured blackboard. Exchange typed claims and artifact references rather than replaying full transcripts in unrestricted group chat.

### Can multiple coding agents edit the same repository?

They should edit isolated branches or sandboxes from an immutable base. A selected or combined artifact must be rebased and fully reverified before one authorized commit.

### How many agents should a workflow use?

Start with one and add branches while the expected marginal verified-outcome value exceeds inference, tool, coordination, verification, queue, and risk cost. Route count by task difficulty and consequence.

### Why is majority vote unsafe for agent actions?

Votes may be correlated and do not establish permission or real-world truth. Use executable evidence and policy checks; keep mutation authority outside the conversation.


## Test yourself

### 1. What is the best reason to add a specialist agent?

- [ ] A new persona name
- [x] A genuinely different tool, evidence source, model, verifier, or critical-path capability
- [ ] More conversation
- [ ] A longer title

**Explanation:** Specialization must add information or control, not only style.

### 2. How many directed edges exist in a 16-agent full mesh?

- [ ] 16
- [ ] 32
- [ ] 120
- [x] 240

**Explanation:** n(n-1) equals 16 times 15, or 240 directed edges.

### 3. Why can five agreeing agents still be wrong?

- [ ] Voting removes evidence
- [x] Their errors may be correlated through shared models, prompts, context, sources, or tools
- [ ] Five is too few to communicate
- [ ] Agents cannot vote

**Explanation:** Majority gains depend on sufficiently independent error and reliable selection.

### 4. What should happen after combining two passing patches?

- [ ] Deploy immediately
- [x] Treat the combination as a new candidate and rerun all checks
- [ ] Average the test results
- [ ] Ask agents to vote

**Explanation:** Individually passing changes can conflict when composed.

### 5. Why did the illustrative three-agent swarm win?

- [ ] It had higher raw success
- [x] Its lower run, verification, and exception cost produced much lower cost per verified outcome
- [ ] It had no verifier
- [ ] It used full-mesh chat

**Explanation:** The eight-agent swarm bought five success points at $161.60 per added success.