I went down a rabbit hole on how Kimi K2's "Agent Swarm" actually works, because the headline numbers — 300 sub-agents, 4,000 steps — aren't the interesting bit. The interesting bit is where the coordination lives. In almost every multi-agent system shipping today, you write the orchestrator: you define the roles, wire the workflow, and hope it holds together as the task grows. Kimi inverts that. The decomposition is a learned policy baked into the weights.
A mode, not a model
Kimi K2 is Moonshot AI's open-weight Mixture-of-Experts model — roughly a trillion parameters total, about 32B active per token. Agent Swarm shipped as a first-class mode in K2.5 (late January 2026) and was scaled up substantially in K2.6 (April 2026). It sits alongside the plain Instant, Thinking, and single-Agent modes; you opt into it for wide, parallelisable work — research sweeps, large extractions, batch generation.
How a run actually works
-
Decompose
The orchestrator reads the task and splits it into independent sub-problems. There are no predefined roles — the breakdown is generated per task.
-
Spawn
It instantiates sub-agents on demand — frozen copies of the base model — each with its own tool access: web search, code execution, file I/O. The orchestrator does this through two interfaces, create_subagent and assign_task.
-
Execute in parallel
Sub-agents run concurrently in a shared workspace, each working its slice. This is where the wall-clock win comes from — complexity that used to scale linearly now collapses into one wide pass.
-
Aggregate
The orchestrator reconciles every sub-agent's output into one coherent deliverable: a report, a spreadsheet, a codebase plan. You see the result, not the scaffolding.
PARL: train the conductor, freeze the orchestra
Only the orchestrator is trained. The workers are frozen.
Moonshot trains this with Parallel-Agent Reinforcement Learning. During training the sub-agents are frozen and their trajectories are excluded from the objective — only the orchestrator gets RL updates. That decoupling is the clever move: it sidesteps the two things that usually sink end-to-end multi-agent training — credit assignment (which agent earned the reward?) and instability — by treating sub-agent outputs as just another environment observation rather than something to backpropagate through.
There's a failure mode they had to engineer around, and it's telling: serial collapse — where the orchestrator quietly gives up on parallelism and falls back to doing everything itself. The fix is staged reward shaping: pay the model for spawning parallel work early in training, then gradually shift the reward back toward "did the task actually succeed." Parallelism has to be made attractive, or the model won't reach for it. That detail alone says a lot about how hard genuine fan-out is to elicit.
K2.5 → K2.6
The architecture didn't change between the two releases — the gain is entirely post-training. And these are Moonshot's own reported figures, so read them as vendor numbers.
Claw Groups: a swarm of agents you didn't build
The K2.6 research preview pushes the idea outward. Claw Groups opens the swarm beyond Moonshot's own clones: agents running different models, on different hardware — laptops, phones, cloud instances — plus human participants, all join one shared workspace. K2.6 acts as the adaptive coordinator: it matches tasks to agents by skill profile, detects when a node stalls, and reassigns the work. You can take over a sub-task mid-run and hand it back without stopping the swarm.
That's a meaningful shift in framing — from "AI does a task for you" to "AI coordinates a team of heterogeneous agents, some of which you built, on your behalf."
Lower friction, until it isn't
The trade is real, and it's about where the control boundary sits. The swarm buys you parallel execution with zero orchestration infrastructure — but decomposition, routing and merge all happen server-side, and via the API you get the final output, not the internal swarm state. The parts that decide whether you'd build on it are exactly the parts that aren't documented: how skill profiles are computed, how shared state resolves two agents writing the same resource, and what happens when the coordinator — not a worker — fails.
Trained-in orchestration is lower-friction right up until you need to explain a run to an auditor or debug a failure. External orchestration costs setup and buys you transparency. Pick your boundary on purpose.
The headline is 300 agents. The actual story is that "write your own orchestrator" is starting to look like a model capability.
Worth understanding now — before it becomes table stakes.