Most of Your Agent Tasks Don't Need a Swarm

In the second week of July 2026, three labs shipped the same idea inside about ten days. OpenAI's GPT-5.6 Ultra now coordinates four agents in parallel by default. Meta's Muse Spark 1.1 can act as a main agent that delegates to subagents or as a constrained subagent that escalates. xAI's Grok 4.5 leaned hard into agentic token efficiency. Parallel subagents stopped being a framework trick you wired up by hand and became a default in the model tier you were already paying for.

So here is the uncomfortable part. Most of the work you point these at will run better on one agent, and the swarm quietly makes it worse.

A swarm is not a general capability upgrade. It is a specific bet: that your task splits cleanly into branches that do not need to talk to each other while they run. When that bet is right, it is one of the best trades in the field. When it is wrong, you pay a large multiple in tokens and latency to get an answer that is less coherent than what a single agent would have produced in one pass.

Two camps, both correct

The confusing thing for anyone reading the field is that the two most credible sources say opposite things.

Anthropic published that a multi-agent system, Claude Opus 4 as the lead with Claude Sonnet 4 subagents, "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval." That is not a rounding-error improvement. That is the swarm justifying its existence.

Cognition, the team behind Devin, published a piece literally titled "Don't Build Multi-Agents." Their argument: "Actions carry implicit decisions, and conflicting decisions carry bad results." Their example is a task split across two subagents building a Flappy Bird clone, where one subagent "mistook your subtask and started building a background that looks like Super Mario Bros," another built a bird in a different visual style, and the lead agent was left with "the undesirable task of combining these two miscommunications."

Both are right. They are describing the two ends of a single axis, and nobody tells you where the line is. That line is the whole decision.

The axis is decomposability, and it runs on reads versus writes

Read the fine print in Anthropic's own post and the condition is stated plainly. Multi-agent systems "excel especially for breadth-first queries that involve pursuing multiple independent directions simultaneously." The keyword is independent. Research is the perfect case: send five subagents to read five different corners of the web, each fills its own context window with sources the others never see, and the lead agent synthesizes the returns. The subagents never need to agree on anything mid-flight, because none of them is changing a shared thing. They are all reading.

Now look at Cognition's failing case. Two subagents writing parts of the same artifact. The bird has to match the background. The physics has to match the art. Every write one agent makes is an implicit decision the other agent needed to know about and did not, because they do not share context while they run. The failure is not that the models are weak. It is structural. You forked the decision-making and then asked a merge step to reconcile choices that were never reconcilable.

So the rule is not "multi-agent good" or "multi-agent bad." It is:

Fan out when the work is read-heavy, wide, and independent. Gathering, searching, surveying, checking many things that do not depend on each other, or a problem whose inputs exceed one context window. Each branch touches its own data and returns a result. Divergence between branches is fine, because a synthesis step at the end is exactly what you wanted.
Keep it single-threaded when agents would write to shared state or when steps depend on each other. Building one coherent artifact, editing one codebase, any pipeline where step two needs to see what step one actually decided. Here, forking the work forks the assumptions, and you pay for it at merge time.

If you cannot draw a clean line down the middle of your task so that each side never has to know what the other is doing, you do not have a parallel task. You have a sequential task you are about to shatter.

The token tax is the tell

There is a hard number that makes this concrete. Anthropic reports that "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens as chats." Fifteen times.

That multiplier is the honest price of a swarm, and it reframes the whole decision as an ROI question, not a capability question. Anthropic says it directly: multi-agent systems "require tasks where the value of the task is high enough to pay for the increased performance." A deep research report a human would have spent a day on is worth 15x the tokens without blinking. A task a single agent finishes correctly in one pass is not, and paying the tax there does not even buy you a better answer. It buys you a worse one, more slowly, for more money.

The same post notes that token usage alone "explains 80% of the variance" in performance on their eval. Read that the right way. Most of what a swarm "figures out" is a function of how much reading it did, not some emergent group intelligence. If the task does not actually require reading more than one agent can hold, the extra agents are burning tokens to look busy.

What to actually do

I build and run agent systems for a living, and the pattern that has survived contact with real work is boring: default to one agent with a well-curated context, and treat fan-out as a scalpel, not the operating table.

Start single-threaded. One agent, continuous context. If it does the job, you are done, and you did it at 1x cost. Most tasks end here.
Reach for fan-out only for read-heavy breadth. Surveying many independent sources, auditing many files for the same issue, running the same check across a wide set. The moment you notice branches would need to negotiate with each other, stop.
If you must parallelize writes, define the interface up front. The reason Cognition's Flappy Bird failed is that the contract lived only in the lead agent's head. If two agents must produce parts of one artifact, write the shared spec first (the exact schema, the exact boundaries) and give it to both, or isolate them so they physically cannot collide, for example one git worktree per agent. You are not sharing context so much as removing the need for it.
Prefer a pipeline over a barrier. When stages are sequential, do not make every item wait for the slowest one before the next stage starts. Let each item flow through all stages independently. Your wall-clock becomes the slowest single chain instead of the sum of the slowest step in each phase. Same agents, a fraction of the waiting.
Instrument the token cost. If you are running multi-agent, watch the 15x. The bill is the fastest way to notice you swarmed a task that never needed it.

The reason this matters more now than a year ago is that the friction is gone. When spinning up five agents meant writing an orchestrator, you thought hard about whether it was worth it. Now it is a default flag on a model you already use, and defaults get used without thought. The labs made the swarm free to reach for. They did not make it free to run.

Parallelism is not a smarter way to think. It is a wider way to read. Point it at problems that are actually wide, and keep everything else on one thread.