Agent Swarms and Research Agents: What Kimi Swarm and Stanford STORM Actually Change

Two different answers to the same problem

Single-prompt AI research has a ceiling. Ask one model to research a topic and you get the majority view, confidently stated, with the same blind spots every time. Ask one coding agent to refactor a large codebase and it stops when the context window fills, not when the job is done.

Two recent designs attack this from opposite directions. Kimi Swarm scales horizontally: one model orchestrates hundreds of small agents in parallel, each with a bounded task. Stanford STORM scales perspective: one model plays five different experts, finds where they disagree, and synthesizes the conflict. Swarms solve breadth. STORM solves depth. Both fail the same way if you skip the system layer.

What Kimi Swarm actually does

Moonshot AI's Kimi K2.6 can orchestrate up to 300 sub-agents across 4,000 coordinated steps from a single prompt. Each sub-agent runs in its own bounded context, and only structured output flows back to the coordinator. The model itself decides the decomposition, builds the org chart, and launches dependent waves as results land.

This is not a chatbot with a bigger context window. It is a batch job where the model is the scheduler. The swarm can emit hundreds of files at once: 40-page reports, 20,000-row CSVs, code repositories, slide decks, and export-ready charts. The unit of output shifts from "a response" to "a deliverable folder."

The economics are what make it practical. Kimi K2.6 is priced at roughly $0.95 per million input tokens and $4 per million output tokens as of August 2026. At that rate, throwing away the first run and rerunning is cheaper than the human time spent debugging a single long-task agent that drowned in its own context.

Write a spec, not a wish

A one-line prompt gives the swarm permission to decide everything, and it will decide wrong. Treat the swarm like a contractor, not a genie. A useful spec defines what to collect, which sources count, the output format, and how conflicts get resolved. Kimi builds the task tree from that spec; it does not replace it.

Lead with the deliverable. "Write a market research report" lets the agent stop early. "Produce a PDF executive summary, a CSV with 20,000 rows of funding data, and 14 export-ready charts" gives the swarm a quality target. The more concrete the output, the more concrete the work.

There is a second reason to be specific. Without constraints, parallel agents can contradict each other. The coordinator sees independent answers and has to guess which one is right. A good spec front-loads the resolution rules so the swarm spends its energy on gathering, not on arbitration.

Verification is the non-optional step

Swarms amplify both speed and error. A cheap run that produces 300 bad answers is not a bargain; it is a cleanup job. The verification gate is what converts volume into trust.

Use a stronger, slower model as the refuter, not the worker. In a Kimi Swarm setup, the sub-agents do the gathering and a frontier model like Claude Opus 5 or Kimi K3 checks the claims. The verifier's only job is to find holes: missing citations, contradictions, confident statements without evidence, and outputs that do not match the spec.

The cheapest verification is structural. Demand that every sub-agent return sources, confidence levels, and a short rationale. Then check that the final deliverable contains those three things. A swarm that cannot show its work is a swarm you cannot trust.

Stanford STORM: research from disagreement

STORM stands for Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking. It was published by the Stanford OVAL Lab at NAACL 2024 and is open source under a permissive license. The live demo is at storm.genie.stanford.edu.

The core idea is simple. When you ask one model about a topic, you get one view. When you force the model to answer as a practitioner, an academic, a skeptic, an economist, and a historian, you get five views. The paper found that articles built this way were judged 25% more organized and 10% broader in coverage than articles built from a single line of questioning.

The five personas are not decorative. The practitioner spots what the academic misses. The economist exposes incentives the historian ignores. The skeptic catches the claim everyone else accepted. The result is a 360-degree map of the topic, not a polished summary.

The STORM workflow in four prompts

You do not need the STORM codebase to use the method. Four prompts in any chat tool reproduce the workflow in about five minutes.

The Stanford authors themselves flag that STORM does not self-critique well. The fourth prompt fixes that. It converts a confident briefing into an honest one, with a reliability score attached.

Where swarms and STORM overlap

Both methods replace the single prompt with a system. In a swarm, the system is orchestration: many agents, bounded contexts, structured outputs, and a verify gate. In STORM, the system is epistemology: many perspectives, contradiction mapping, synthesis, and peer review. The swarm asks more questions in parallel. STORM asks better questions.

They can be combined. A swarm can run the STORM method at scale: one sub-agent per persona, each reading a different subset of sources, with a verifier checking the contradiction map. That is probably overkill for a blog post, but it is the right shape for due diligence, literature reviews, or competitive analysis across hundreds of sources.

Build the compounding loop

The real payoff of either method is not one good run. It is the loop that makes the next run better. After a repeatable swarm or research job, capture what worked as a reusable skill or constraint file. Every verified mistake becomes a rule. Every verified success becomes a template.

This is how the system gets smarter without retraining the model. The model weights stay the same. The harness around them improves. A month of disciplined feedback turns a generic research agent into one that writes like your team, cites the sources you trust, and avoids the mistakes you already made.

When to use which approach

Tools that fit the workflow

Kimi K2.6 is the model most closely associated with the swarm architecture, but the pattern works with any model that supports tool use and structured output. Claude Code and Google Antigravity provide multi-agent orchestration for coding work, while Manus AI and OpenAI Frontier target broader agent workforces.

For research specifically, STORM is model-agnostic once you have the four prompts. Perplexity Sonar Deep Research and NotebookLM already bake in multi-source synthesis. ChatGPT Atlas, Google Chrome, and Microsoft Edge Agentic OS are adding agentic browsing so the research itself can be delegated, not just the writing.

Four controls that keep either method safe

Both methods become dangerous when the human stops paying attention. The controls are the same as for any autonomous system: a budget, a timeout, a stop condition, and a verifier.

• Budget. Set a hard dollar cap per run. A swarm with no cap can make hundreds of API calls before anyone notices.
• Timeout. Limit the total number of steps or the wall-clock time. A research agent can keep refining forever.
• Stop condition. Define success in advance: a test passes, a file exists, a contradiction map is complete.
• Verifier. A separate model, or a separate prompt, whose only job is to refute the output.

Without these four, the new ability to run 300 agents or five perspectives just means you can produce wrong answers faster. With them, the same architecture can handle work that used to take a team a week.

For the cost side of running autonomous agents, see the guide on AI agent cost control. For setting up the coding agent that might sit inside a swarm, read getting more out of a coding agent. For the protocol that lets agents call tools, see agent tool architecture and MCP.