AI agent swarms are a massive waste of money, and one OpenAI developer just proved it

The pitch sounds compelling. Instead of one AI agentAI agentSoftware that pursues a goal on its own: it plans steps, uses tools and takes actions with limited human input.View full definition → grinding through a task sequentially, deploy a swarm: ten agents, fifty agents, each attacking a sub-problem in parallel, their outputs merged into something greater than the sum of its parts. The demos look impressive. The architecture diagrams fill conference slides. And in 2026, every major vendor is positioningpositioningThe mental space you want your brand to occupy in your target customer's mind relative to alternatives.View full definition → their platform as swarm-ready.

Then an OpenAI Codex developer published a frank assessment: agent swarms are a massive waste of tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → with zero quality gain. That kind of statement, from someone building one of the most-watched agentic coding tools in the industry, deserves more than a retweet.

The case for parallel agent swarms

The case for agent swarms has real intellectual weight. Decomposing a large problem into parallel workstreams mirrors how human teams operate. A research task can be split across agents that fetch data, summarise sources, check for contradictions, and draft conclusions simultaneously. Compared to a single agent churning through the same steps serially, the wall-clock time drops. At scale, the architecture seems rational.

The broader context supports this direction. Anthropic is actively pushing Claude Code toward autonomous coding workflows with parallel agent configurations, as reported by The Decoder in September 2026. Multi-agent frameworks have moved from research projects to shipping products. The reasoning is not naive: if a single agent has a context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition → and an attention budget, why not distribute the cognitive load?

For tasks with genuinely independent sub-components, the parallel structure has a theoretical basis. The consensus is not wrong because the idea is absurd. It is wrong because the theory rarely survives contact with what tokens actually cost, and with how quality actually behaves at the seams between agents.

Do agent swarms improve output quality?

The Codex developer's claim is specific: no quality gain, and substantial tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → waste. That specificity matters. Token consumption is not an abstraction. OpenRouter's token usage chart from mid-2026 showed consumption curves that have prompted genuine debate about whether current AI usage patterns are economically sustainable. When you run a swarm, each agent maintains its own context, executes its own reasoning steps, and produces its own output that a coordinator then has to parse. The overhead is multiplicative.

The quality problem is subtler. Agent outputs have to be reconciled. The coordinator, whether another LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → call or a deterministic merge, has to resolve conflicts, fill gaps left by agents that misunderstood their scope, and produce coherent final output. Every handoff is a failure surface. The Decoder's item on rogue agent oversight captures the second-order problem: agents act faster and at greater volume than humans can realistically review, which means errors compound before anyone catches them.

KDnuggets published analysis showing that token usage in search-result contexts can be cut by up to 74% through smarter formatting choices. That figure is relevant here because it illustrates a broader principle: most token waste in agentic systems is architectural, not inevitable. You do not need to run ten agents to process ten documents if a single well-structured agent with efficient input formatting can process them sequentially in less total compute. The swarm adds coordination overhead while the underlying inefficiency in context handling goes unaddressed.

There is also a reliability dimension that the swarm literature largely ignores. In production, understandinghow cost, latency, and reliability interact exposes a brutal trade-off: more agents means more APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → calls, more points of failure, more latency variance, and more unpredictable billing. A single agent failing mid-task is a recoverable event. Five agents failing at different points in a parallel workflow, with partial outputs that the coordinator now has to handle gracefully, is an engineering incident.

The Anthropic push toward parallel agent workflows is real, but worth reading carefully. Anthropic is a vendor with a commercial interest in workflows that consume more Claude tokens. That does not make the capability useless, but it means their documentation should not be treated as neutral evidence that swarms outperform single-agent approaches on quality metrics.

How to choose between a single agent and a swarm

First, stop treating agent count as a proxy for sophistication. The instinct to add more agents to a hard problem mirrors the instinct to throw more junior analysts at a report. More bodies rarely improve the thinking; they multiply the coordination tax.

Second, audit where the tokens actually go. Before spinning up any multi-agent architecture, run the single-agent version and measure output quality against a human-graded rubric. If the single agent hits 80% of the quality bar at 10% of the token cost, the swarm needs to justify the gap with specific evidence, not theoretical appeal.

Third, distinguish the cases where parallel agents genuinely help. Truly independent sub-tasks with no shared state and no required coherence at the output stage are reasonable candidates. Code testing across isolated modules, data retrieval from separate sources that will be displayed separately, or parallel translation pipelines where outputs never need to merge are examples where the swarm structure adds speed without adding coordination risk. Understandinghow the perceive-plan-act-observe loop works in a single agent before adding a second agent is not a beginner exercise; it is the professional standard.

Fourth, watch the coordination layer. The orchestrator in any multi-agent system is where quality actually lives or dies. If your orchestrator is another LLM call that has to reconcile conflicting agent outputs, you have not distributed the hard problem, you have deferred it and made it harder. Build the orchestrator to be deterministic wherever possible, and reserve LLM judgment for cases where rules genuinely cannot handle the decision.

The Codex developer's critique is a useful corrective against a trend that is driven more by architectural aesthetics than by production evidence. Swarms are not categorically wrong, but they are almost never the first tool to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for. A well-designed single agent, with clean inputs and a clear task scope, outperforms a poorly coordinated swarm on cost and reliability in most real-world deployments. That is the conclusion the token data keeps pointing toward, and practitioners who internalize it early will ship better systems than those who are still debugging their orchestration layer six months from now.