I watched a guy on LinkedIn last week demo his "autonomous agent swarm." Forty-three agents. A research agent, a planning agent, a coding agent, a review agent, a deployment agent, a monitoring agent, agents that existed solely to coordinate other agents. The architecture diagram looked like a motherboard. The comments were full of fire emojis.
And I felt the pull. That flicker of being behind. The itch to go architect something impressive, something with boxes and arrows and the word "orchestration" in the README. I opened a blank file. Started sketching.
Then I closed it. Because I recognized the feeling. It's the same one I wrote about in Your Stack Is Fine — the feeling of solving a problem that doesn't exist yet so you can avoid the one that does. The swarm is just the newest costume.
The seductive frame
The pitch goes like this: you're an artisan. You do everything by hand. That's charming but it doesn't scale. The natural evolution is artisan to assembly line. You break the work into stations, assign each station to an agent, and now you're an industrialist. Throughput goes up. You graduate from maker to manager. It sounds like maturing.
And if you squint, it looks right. The maker does become a line manager. The architecture does get more complex. It does feel like moving from craft to industry. The metaphor flatters you. It says you're not tinkering anymore. You're operating.
Why the metaphor is wrong
Assembly lines work because they standardize repetitive, identical output. Every station does the same thing, thousands of times, with minimal variation. The whole point is to deskill each step so it can be executed without judgment. That's where the efficiency comes from.
Agent swarms do the opposite. Each agent handles a different kind of cognitive work: research, synthesis, code generation, evaluation. And every task is different from the last. You're not building an assembly line. You're recreating a committee.
And committees have a coordination tax. Every agent needs context. Context has to be passed, summarized, compressed, or reconstructed at each handoff. Decisions that one mind would make in a single pass now disperse across multiple agents, each working with a partial view, producing mush that a meta-agent has to reconcile.
I spent five years at Dell watching this happen with humans. It's the Mythical Man-Month in a new hat. You add agents, you add communication overhead. The overhead fragments context. The fragmented context produces worse decisions dressed up in better formatting. You're speed-running the exact org dysfunction you left a big company to escape.
The split that should stop you
The people closest to this technology can't agree on whether multi-agent is even a good idea.
Anthropic has published research arguing for multi-agent systems in specific research contexts: parallel exploration, breadth-first search across large solution spaces. At the same time, Cognition published a piece called "Don't Build Multi-Agent Systems," arguing they're fragile, hard to debug, and almost always worse than a well-prompted single agent. A spring 2026 Stanford preprint found that single agents match or beat multi-agent swarms at equal token budgets in most benchmarks.
The people building the models can't agree. So when someone on your timeline presents multi-agent as "the obvious next step," that's not an engineering consensus. It's a fashion.
What's actually true
The shift from maker to orchestrator is real. But the craft moved up, not out.
The real skill now is judgment: how to break a problem down so an AI can handle it. How to feed it enough context without drowning it. How to check output that sounds right but might not be. And the one nobody talks about: knowing when not to add an agent. Subtraction doesn't get fire emojis.
A brigade chef designs which stations exist in a kitchen, what each one handles, how the flow works. The skill isn't "managing more cooks." It's knowing the minimum number of stations that produce the best plate. Adding stations you don't need doesn't make the food better. It makes the kitchen slower.
The diagnosis
Agent count is a vanity metric. Same lineage as lines of code, microservice count, and the burndown chart that always looks perfect because nobody logs honestly.
A 40-agent architecture is the most sophisticated procrastination available to a builder in 2026. It feels like progress. It looks like engineering. The architecture diagram is genuinely impressive. You can spend weeks on orchestration patterns, error-handling cascades, agent-to-agent protocols. None of it faces a user. None of it tests whether someone outside the room wants what you're building.
It feels like the cloud. It's still not a customer.
When multi-agent actually makes sense
I'm not a luddite. Multi-agent has real uses. They work when the subtasks are truly independent and parallel. When you need to search ten databases simultaneously, or evaluate a solution against five different criteria where each evaluation is self-contained. Breadth-first work with no shared state. That's the assembly line use case done right: identical stations, parallel throughput, no coordination tax.
But that's a narrow engineering decision, not an identity. And you'll know you need it because you'll hit the wall with a single agent first. If you haven't hit that wall, you don't need the swarm. You want it. There's a difference.
The question
The question isn't "how many agents." It's "what does one of them ship that someone outside the room would pay for."
If the answer is clear and you need parallelism to deliver it, add agents. If the answer isn't clear, if you haven't validated that anyone wants the thing the swarm is building, then you're not orchestrating. You're decorating.
I wrote in The Build Trap Got Cheaper that AI made it possible to build indefinitely without ever facing reality. The swarm is the final form of that trap. A factory with no shipping dock.