The Agent Swarm Problem

4 min read

Every week I see another post about someone’s “swarm” of 20, 50, or 200 AI agents working in parallel. The screenshots are beautiful. The demos are impressive. And then you ask how many of those agents actually produce reliable output in production. The number drops fast.

There is a real, measurable problem with agent swarms: hallucinations compound non-linearly.

One agent hallucinates a false fact. It passes that fact to the next agent, which builds on it. That agent’s output goes to three more agents, each adding their own confident fictions. By the time the swarm finishes, you have a beautifully formatted, perfectly structured piece of garbage that sounds authoritative about things that never happened.

This is not a theoretical edge case. This is what happens every time someone throws 50 agents at a task without thinking about error propagation. Each agent has a baseline error rate. In a serial chain, those rates multiply. In a DAG with fan-out, they spread exponentially. A 95% accuracy per agent becomes 77% after five sequential calls, then 60% after ten. Throw in branching and parallel workers, and your effective accuracy collapses.

The temptation is to solve this by adding more agents: a fact-checker agent, a validator agent, a meta-reviewer agent. Now you have a 15-agent pipeline to write a blog post. Each new agent adds latency, cost, and another chance for the system to drift. You haven’t fixed the problem. You’ve made it more expensive to observe.

Practical guardrails I have started using:

First, max depth of 3. No agent chain should be deeper than three hops. Beyond that you lose traceability. Second, explicit hand-offs only. Do not let agents route to each other automatically. You write the routing or you accept the chaos. Third, vet inputs before they enter the chain. Garbage in, gospel out. If agent 1 produces bad output, the rest of the swarm should never see it. Kill the thread early.

Fourth, measure your hallucination rate. Run a test harness. Take 100 inputs, check the outputs manually, and track where the chain breaks. If you cannot name your per-agent accuracy rate, you do not have a swarm. You have a lottery.

The most honest teams I know of are running swarms of 3 to 7 agents in production, not 50. They have hard limits on depth. They monitor error propagation. They treat agent orchestration as what it is: a distributed systems problem with probabilistic outputs. The probabilistic nature is what makes it hard. Acting like it is not hard is how you end up with impressive dashboards and unusable results.

More agents is not better. Controllable, observable, limited-depth orchestration is better. Everything else is a demo.