The pitch this month is “300 agents.” One model can now spin up three hundred of them at once, working in parallel, on a single task. The number is doing a lot of heavy lifting on Twitter right now, and most of the takes amount to: more agents, more better.

That’s not how it works. I run AI agents every day to do real work — not demos, actual systems that cost real money when they break. So when two of the biggest agent platforms ship two completely different answers to the same question, I pay attention to the architecture, not the headline. Because the headline number is the least interesting thing about either of them.

Here’s the honest breakdown of what’s actually different, and how to tell which one your work needs.

The Two Bets

There are two ways to throw multiple AI agents at a problem, and the industry just split cleanly down the middle.

The swarm. Moonshot’s Kimi K2.6 ships with what they call Agent Swarm: one coordinator model breaks a task into pieces and fans them out to up to 300 sub-agents, running across up to 4,000 coordinated steps. That’s a real jump — the previous version capped at 100 sub-agents and 1,500 steps. You give it one prompt through a web interface, it shreds the work into parallel threads, and a coordinator stitches the results back into one deliverable. Moonshot says swarm mode cuts end-to-end time by up to 80% on the right tasks, with a measured speedup around 4.5x. In one of their own examples, it rebuilt an 8-year-old open-source matching engine over a 13-hour run — more than 1,000 tool calls, 4,000-plus lines of code changed.

The team. Anthropic’s Claude Code Agent Teams goes the other direction. Instead of a swarm, it runs a small team — in practice 4 to 20 agents — coordinated by an orchestrator, working inside your actual codebase from the terminal. To stress-test it, a team of 16 agents was pointed at writing a C compiler from scratch in Rust. Across roughly 2,000 sessions and about $20,000 in API spend, they produced a 100,000-line compiler that builds the Linux kernel on x86, ARM, and RISC-V.

Three hundred agents on one side. Sixteen on the other, building a compiler. Both are “multi-agent.” They are not the same product.

Clearing Up One Myth First

You’ll read that the difference is “centralized vs. peer-to-peer” — that the swarm uses one coordinator while the team lets agents talk directly to each other. That’s wrong, and it matters if you’re trying to reason about which to trust.

Both route through a coordinator. In the swarm, every sub-agent reports up to the coordinator; there’s no agent-to-agent chatter. In Claude’s teams, the agents also don’t message each other directly — they coordinate through the orchestrator and a shared task list. An agent finishes its piece, hands the result back up, and the orchestrator decides what context the next agent needs.

So the real difference isn’t the communication model. It’s two things:

Scale — 300 parallel workers vs. a focused handful.
Surface — a general-purpose web tool that produces files, vs. a terminal tool living inside a codebase that produces working software.

Once you see it that way, the “which is better” question dissolves. They’re built for different jobs.

What a Swarm Is Actually Good At

Breadth. Anytime the work is wide — lots of independent pieces that don’t depend on each other — the swarm wins, because that’s exactly the shape parallelism eats for breakfast.

A literature review across 40 papers becomes 40 agents reading 40 papers at once.
A market scan of 30 competitors becomes 30 parallel investigations folded into one report.
“Tailor this resume to these 100 job listings” becomes 100 customized drafts in a single run.
Batch generation — dozens of landing pages, posts, or covers, each slightly different — done in one pass instead of one at a time.

The common thread: the subtasks barely touch each other. Each agent can run in its own lane and the coordinator just collects the lanes at the end. When your bottleneck is coverage — too many sources, too many files, too many variations to do by hand — a swarm turns days into minutes.

What a Team Is Actually Good At

Depth. When the pieces of the work are tangled together — change one thing and three other things have to move with it — you don’t want 300 agents stepping on each other. You want a small team that understands the whole picture.

That’s a codebase. Refactor an API and every caller has to change, the tests have to change, and something three files away might quietly break. That’s not a “fan out to 300 lanes” problem; it’s a “five careful agents who share context” problem. The compiler example isn’t impressive because of the agent count — it’s impressive because 16 agents held a single coherent system in their heads across 2,000 sessions without it collapsing into mush.

Tight interdependence rewards a team. Wide independence rewards a swarm. That’s the whole rule.

The Number Is a Trap

Here’s the part nobody selling you “300 agents” wants to dwell on: the agent count is a system limit, not a quality setting. Three hundred agents and 4,000 steps describe what the system can spin up. They say nothing about whether the output is any good.

I’ve watched this play out enough times to be blunt about it. Vague input gets you vague output — at 300 agents, you just get vague output faster and in larger volume. Parallelism multiplies whatever you fed it. If the instructions were sloppy, you don’t get one mistake to catch; you get the same mistake copied across a hundred deliverables.

Two things actually decide whether any of this works, and neither is the agent count:

Decomposition. Can the work even be broken into clean, independent pieces? “Analyze the AI industry” can’t — it’s a mush of a prompt and you’ll get mush back. “For each of these 30 companies, pull funding, top products, main competitors, and current valuation into one row of a table” can — it’s already shaped like 30 lanes. The skill isn’t typing a prompt. It’s seeing the seams in your own work.

Verification. The system hands you real files, not a starting point — which is exactly why you have to check them before anything goes live. Speed without verification doesn’t produce scaled-up value. It produces scaled-up errors. The faster the machine, the more discipline you need on the way out, not less.

That second one is the whole game for operators. The win isn’t “the AI did it.” The win is “the AI did it and I can trust it,” and trust comes from a human reading the output before it touches a customer.

So Which One Do You Reach For?

Skip the brand loyalty. Ask what the work looks like.

Reach for a swarm when the job is wide and shallow: broad research across many sources, batch generation of many similar things, processing a pile of files, any task where the bottleneck is sheer coverage and the pieces don’t depend on each other. One prompt, one synthesized deliverable, no code required.

Reach for a team when the job is narrow and deep: anything inside a codebase, anything where the pieces are interdependent, anything where you need agents to challenge each other and hold a single system coherent. Fewer agents, more judgment, real software out the other end.

And reach for neither when the honest answer is “this is one focused task for one agent.” Most work still is. Not everything needs a factory.

The Real Edge

The operators who pull ahead this year won’t be the ones who picked the platform with the bigger number. They’ll be the ones who got good at two unglamorous skills: breaking their own work into pieces a machine can run in parallel, and checking the output before it ships.

The 300 agents are real. The speed is real. But speed has always been the easy part. The edge has never been how fast — it’s whether you can trust what comes out the other side fast enough to keep up. Build that habit first. The agent count will take care of itself.

Figuring out where AI actually creates leverage in your operation — and where it just creates faster mistakes — is most of the work. If you’re staring at that question, come find me on @xovionai.