Swarm architectures are seductive. Spinning up five agents in parallel feels like progress. But it is also the fastest way to spend 10x the tokens and get back half the quality of a single well-prompted agent.
This is an honest cost-benefit breakdown. No hype, just the cases where swarms actually win.
—
The two task types where swarms genuinely outperform single agents
Most swarm use cases are not actually better than single agents. Two categories are the exception.
Parallel research. When you need to gather information across five unrelated sources simultaneously and synthesize it afterward, a swarm saves real wall-clock time. The agents are not coordinating mid-task, they are just running in parallel and handing off results. That is the easy case and it works.
Adversarial review. One agent generates a draft. A second agent is explicitly prompted to challenge it, find gaps, and push back. This works because the second agent is not trying to be consistent with the first – it has a separate context and a different job. You get genuine tension rather than a single agent second-guessing itself in the same context window.
Outside these two categories, think carefully before adding agents.
—
Why shared state is the hard part
Most swarm failures are not agent failures. They are state failures.
The classic pattern: Agent A reads a file, starts processing it, and writes a partial result. Agent B reads the same file, does not know about Agent A’s progress, and either duplicates the work or overwrites it. Neither agent errored. The coordination logic did.
Specific patterns to watch for:
- Missing locks. Two agents writing to the same output file or database record with no mutual exclusion. The last write wins, silently.
- Stale reads. An agent reads shared state at the start of its run and makes decisions based on it. By the time it acts, another agent has changed that state. The first agent is now operating on false premises.
- Dependency gaps. Agent B depends on Agent A completing step 1 before starting. You think you modeled this dependency, but under load or retry conditions, the ordering breaks and no one catches it.
The rule: define your shared state contract before you design your agents. What does each agent read? What does it write? Who arbitrates conflicts? If you cannot answer these cleanly, the swarm will fail in ways that are hard to debug.
—
Tool conflict patterns
Agents interfering with each other’s tools is underrated as a failure mode.
Examples:
- Two agents both call a search API at the same rate, triggering rate limits that neither would hit alone
- One agent deletes a temp file that another agent is mid-read on
- Two agents both send a draft email because neither checked whether the other had already sent it
Solutions that work:
Namespace outputs. Each agent writes to its own directory or key prefix. Merge is a separate explicit step, not implicit shared access.
Idempotent tool calls. Design tools so calling them twice has the same result as calling once. This will not prevent conflicts but it will prevent them from causing data corruption.
Explicit locks for write operations. If two agents might write to the same resource, the tool should enforce a lock. Do not rely on agents to coordinate through prompting alone.
—
The cost model
Before committing to a swarm design, run this estimate.
- Token cost per agent run. Estimate input + output tokens for one agent completing its share of the task.
- Number of agents and coordination overhead. Add orchestrator tokens, state management calls, and any merge/synthesis step at the end.
- Expected quality gain. Be specific. Is the output measurably better? By how much? Is that gain from the swarm or from more compute that could have been applied to a single agent?
- Failure rate multiplier. Swarms fail more often. Add a 20-30% buffer for retries, coordination errors, and debugging time.
If the total cost is more than 3x a single-agent approach and the quality gain is marginal, default to the single agent. You can always add parallelism later.
The common mistake is building swarm infrastructure first and then trying to justify it. Start with one agent. When you hit a specific, demonstrable limit, that is when to reach for coordination.
—
Quick summary
- Swarms win for parallel research and adversarial review. That is about it.
- Shared state failures are the number one cause of swarm bugs. Define the contract before the agents.
- Namespace outputs and use idempotent tools to avoid silent conflicts.
- Run a cost estimate before building. Most swarm designs cost 3-10x more than they look like they will.
What patterns have you hit with multi-agent coordination? Curious what failure modes others have run into.
