What a swarm of agents actually does (and why Kimi Work is built out of one)

Moonshot AI shipped a desktop agent yesterday called Kimi Work, and the headline word in the announcement is "swarm". I want to walk through what that word actually means in this context, because it has moved very fast from research-paper jargon to product-marketing wallpaper, and the gap between those two uses is wide enough to fall into.

A swarm, in agent-architecture terms, is a coordinated group of specialised sub-agents that take on a slice of a larger task and pass work between them. It is a real pattern with real trade-offs, and it is now the architecture behind several mainstream agent products. Here is how it works, where it pays for itself, and where it tends to break.

The problem swarms exist to solve

Start with the failure mode of a single agent. You ask one model to write a long research report. It searches, reads, drafts, edits, fact-checks, and formats — all in one long chain of reasoning, with one context window holding everything. By step thirty, the context is crowded, the early instructions have faded, and a single confused turn corrupts everything downstream. The model is doing five jobs and getting tired at all of them.

The swarm pattern says: don't do that. Split the job. Have one agent search, another read and summarise, another draft, another verify. Each one gets a clean context window, a narrower instruction, and a smaller surface area to mess up on. A coordinating agent, the orchestrator, decides who runs when and what each one sees.

That is the whole idea. The interesting questions are all in the details.

The shape of the pattern

A swarm has three moving parts.

The orchestrator. This is the agent that receives the user's task and decides how to break it down. It is usually itself an LLM, prompted to act as a planner. It outputs a plan — a list of sub-tasks, the agent type each one needs, and the order they should run in. Moonshot says its K2.6 orchestrator can coordinate up to 4,000 steps across up to 300 sub-agents on a single task. Those numbers are the orchestrator's job to hold together.

The sub-agents. Each sub-agent is a model instance (sometimes the same underlying model, sometimes a smaller specialised one) given a narrow role: searcher, coder, writer, analyser, tester. It gets a fresh context window containing only what it needs — the orchestrator's instruction, the relevant prior outputs, and access to whatever tools its role implies. A searcher gets web search. A coder gets a shell and a file system. A writer gets neither and is told to focus.

The handoff protocol. This is how work moves between agents. In OpenAI's reference swarm library, a handoff is just a function call: agent A calls transfer_to_agent_B() and the framework swaps in B's system prompt and tools. The shared state is whatever A chose to pass along. Other frameworks use message queues, shared scratchpads, or a blackboard pattern where agents read and write to a common workspace. The protocol choice determines what "coordination" actually costs.

A worked example

Imagine you ask Kimi Work to produce a competitive analysis of the European EV charging market.

The orchestrator reads the request and writes a plan: identify the major players, pull recent financial filings, summarise each company's strategy, build a comparison table, draft a narrative analysis, fact-check the numbers, format the output.

It then spawns sub-agents. Three searchers go to work in parallel, each on a different slice of the market. Their outputs land in a shared workspace. A reader-agent ingests those raw results and produces clean summaries. A writer-agent takes the summaries and drafts the analysis. A verifier-agent re-checks every quoted number against the source documents the searchers pulled. A formatter assembles the final document.

The wall-clock saving comes from parallelism. The three searchers run at the same time, not sequentially. The quality lift, if it materialises, comes from each agent having a clean context and a single job. The orchestrator is the only component that has to hold the whole task in its head, and it only has to hold the plan, not the content.

Where the pattern breaks

Swarms have three well-documented failure modes, and any honest explanation has to name them.

Error cascades. If the searcher returns bad sources, the reader summarises bad sources, the writer drafts from bad summaries, and the verifier, checking against the same bad sources the searcher pulled, confirms the bad numbers. No human is in the loop between stages. One early mistake propagates through every downstream agent, and the final output looks confident because each stage did its narrow job correctly.

Coordination overhead. Every handoff is an extra LLM call. Every sub-agent invocation has its own latency and token cost. A swarm that uses ten agents to do a job a single agent could do in one pass is paying ten times the inference cost and waiting for the slowest agent at every join. The break-even point is real, and it is further out than the marketing suggests.

Lost context on handoff. The sub-agent only sees what the orchestrator passes it. If the orchestrator's summary of "what we know so far" drops a critical nuance, the sub-agent has no way to recover it. This is the multi-agent version of the telephone game, and it gets worse as the agent count grows.

These are not reasons to avoid swarms. They are reasons that the pattern is justified only when the task genuinely benefits from parallelism or specialisation — long research reports, multi-file codebases, end-to-end office workflows. For a focused single-step task, one good agent in one good loop almost always wins.

What I cannot tell you yet

Moonshot has not published an architecture paper for Kimi Work. The "swarm" label is real in the sense that K2.5 and K2.6 were trained as orchestrators with explicit multi-agent decomposition, and the published numbers (300 sub-agents, 4,000 steps) are specific enough to be meaningful. But the desktop product itself has not been independently benchmarked, and there is no model card showing how the orchestrator decides when to spawn agents versus when to handle a task itself. That decision, the routing policy, is the hardest unsolved problem in multi-agent systems, and it is the thing I would most want to see documented.

The other thing to watch is how Kimi Work handles tool access. The Model Context Protocol, which most agents now use to call out to external tools, was specified as a 1

client-to-server session. A swarm with 300 concurrent sub-agents all wanting to hit the same MCP server is not what the protocol was designed for. Either Moonshot has solved session multiplexing in a way they have not described, or each sub-agent is running its own MCP session in parallel, which works but multiplies the infrastructure footprint. I would like to see which.

Glossary

Swarm architecture A multi-agent design where an orchestrator splits a task among specialised sub-agents and coordinates their outputs.

Orchestrator The planning agent that decomposes a task, decides which sub-agents to invoke, and assembles the final output.

Sub-agent A model instance given a narrow role (searcher, writer, verifier) with its own context window and tool access.

Handoff The mechanism by which one agent passes work and context to the next; often a function call or a shared scratchpad write.

MCP (Model Context Protocol) Anthropic's standard for letting a model call external tools through a defined client-server session.

Context window The amount of text a model can hold in working memory at once when producing output.

Footnotes and links

Further reading

• Microsoft Research, AutoGen documentation and the multi-agent conversation framework: https://microsoft.github.io/autogen/
• OpenAI swarm library cookbook examples: https://github.com/openai/swarm/tree/main/examples
• Moonshot AI Kimi K2.6 release notes for the orchestrator scaling numbers cited above.

¶