Kimi K3 Swarm for Market Research: A Full Workflow

Running market research on Kimi K3 Swarm is not really a prompting problem. Moonshot’s own help documentation describes an orchestrator that can deploy up to 300 subagent instances and drive more than 4,000 tool calls inside a single task, and the fan-out genuinely works. What determines whether the output is worth reading is the step after it: reconciling dozens of independently gathered, partially overlapping, occasionally fabricated findings into one defensible brief.

Most coverage of Agent Swarm stops at the headline — 300 agents, 4.5 times faster than sequential execution, BrowseComp accuracy up from 15.9% to 33.3%. Those are the vendor’s own numbers from its own help pages, and they describe the cheap half of the job. The expensive half is that a wide fan-out multiplies your raw material and your error surface at exactly the same rate. More agents means more sources, more duplicate coverage, more contradictions, and more citations that need checking before a client sees them.

This is one worked workflow, end to end: how to pick the fan-out axis, how to write subagent briefs that do not collide, how to run a cheap automated citation pass before a human touches anything, how to structure the human review using established market-research triangulation practice, and how to keep the credit bill in proportion to the value of the question. Whether a given research question should be parallelised at all is a separate decision, and we treat it separately in the decomposability test for when Swarm is worth the credits. This post assumes you have already answered yes.

Moonshot’s Agent Swarm help page describes an orchestrator — it uses the word coach — that decomposes a task and deploys subagents to work the pieces in parallel. The documented ceilings are up to 300 subagent instances and more than 4,000 tool calls in a single task. The vendor reports Swarm running 4.5 times faster than sequential execution by a single agent, and reducing critical steps by 3 to 4.5 times in large-scale search scenarios.

The training design is the interesting part, because it explains why the orchestrator behaves the way it does. Moonshot’s help documentation states that only the coach is trained: subagent capabilities stay frozen while the orchestrator alone improves through reinforcement learning, which keeps credit assignment clean. The vendor’s GitHub-hosted mirror of the same help page goes further and describes a three-dimensional reward function that penalises orchestrator laziness, scoring final result quality, the true parallelism actually achieved, and sub-task completion rate. That detail is vendor-documented via the mirror rather than visible on the live page render, so treat it as documentation of intent rather than a benchmark.

The documented ideal task types tell you what the system was built for: large-scale information retrieval, batch file downloads, broad reading across 100 or more documents, long-form writing above 100,000 characters, complex programming, and office automation. Competitive and market research sits squarely inside the first and third of those. It does not sit inside the vendor’s own stated limitation, which is the sentence worth pinning above your desk.

That limitation is the line between a research question Swarm makes cheap and one it makes expensive. Twelve competitors, each audited against the same seven feature dimensions, decomposes perfectly: nothing agent 4 finds changes what agent 9 should search for. A research thread that needs the output of one step to know what to ask next — follow the funding trail, then the hires it paid for, then the product those hires shipped — does not decompose, and forcing it into a fan-out buys you 300 shallow passes over the first hop. If you want the underlying model’s spec sheet rather than the orchestration layer, we covered that in K3’s open-weight release and full spec sheet.

The single decision that determines whether a Swarm research run merges cleanly is the axis you slice the question along. An axis is good when two properties hold: the slices are mutually exclusive, so no two agents can legitimately return the same finding, and the slices are individually answerable, so no agent needs another agent’s output to complete its own.

Moonshot’s own documented examples are a useful catalogue of axes. The YouTube Niche Analysis example finds the top three creators across 100 niches, spinning up roughly one search specialist per niche and consolidating into a structured table of channel names, subscriber counts and descriptions — that is a per-segment axis. The Product Launch Review example deploys expert subagents with distinct assigned perspectives, a product manager, a sceptical investor, a customer-success lead, to critique a launch from multiple angles — that is a per-persona axis. The Essay Collection and Literature Review examples, gathering 200-plus essays into topic folders and condensing 40 PDFs into a cited document, are per-document axes. Swap creators for competitors and niches for market segments and you have most of what agency research actually asks for.

The instruction each subagent receives matters as much as the axis. Anthropic, documenting its own Claude-based multi-agent research system in a June 2025 engineering write-up, found that the fix for overlapping subagent work was not architectural but prompt-level: each subagent needed an objective, an output format, guidance on the tools and sources to use, and clear task boundaries, rather than a vague topic. That is directly transferable here. A subagent brief that reads “research Competitor B” will return whatever the model finds interesting; one that reads “return Competitor B’s published list price per seat per month for each named plan tier, as a table, sourced only to the vendor’s own pricing page, and return null where no public price exists” returns something you can merge.

This table is ours, not the vendor’s. It maps the five research-question types an agency actually gets asked for against the fan-out axis each one wants, the subagent band we would plan for, the merge failure each one is most prone to, and the human checkpoint that catches it. The axes and example shapes come from Moonshot’s documented Swarm examples; the failure modes are drawn from Anthropic’s published account of its own multi-agent system and from the citation research in section 05; the checkpoints come from established market-research triangulation practice covered in section 06.

The subagent bands are our planning recommendation, not a vendor specification. Read them alongside the concurrency caveat in section 07 — on a tier whose published cap is 2, a band of 40 is a queue depth, not a burst.

The pattern across the rows is that merge risk changes shape as the fan-out widens rather than simply getting worse. Narrow runs fail on contradiction — a small number of agents return conflicting facts about the same entity and someone has to adjudicate. Wide runs fail on redundancy and fabrication — hundreds of findings arrive, most of them fine, a handful invented, and nobody has time to read all of them. Those are different review jobs, and staffing a wide run with the review process designed for a narrow one is the most common way a Swarm research deliverable goes out wrong.

The best-documented account of what goes wrong in a wide research fan-out does not come from Moonshot. It comes from Anthropic’s engineering write-up on its own Claude-based multi-agent research system, published 13 June 2025 — a comparable orchestrator-and-subagent architecture, and the reason the failure modes it names are worth borrowing even though the system is not Kimi.

The economics in that same write-up explain why the failure is expensive rather than merely untidy. Anthropic reported that multi-agent systems in its setup used roughly 15 times more tokens than a single chat turn, against roughly 4 times for a single research agent working alone, and that token usage by itself explained 80% of the variance in browsing-task performance. Both figures describe Anthropic’s own Claude-based system, not Kimi K3 or Agent Swarm. Read together they say something uncomfortable: spend buys quality fairly reliably, so a duplicated subagent is not just wasted money, it is quality you paid for and did not receive.

Anthropic also stated plainly where multi-agent architectures fail outright — when all agents must share identical context, when tasks involve heavy interdependencies between agents, or when the domain needs real-time coordination, with most coding tasks given as the example. Market and competitive research sits on the favourable side of that line when the question has many independent units, and on the wrong side when it is one evolving narrative thread. That is the same distinction Moonshot’s own parallel-friendly caveat draws, arrived at from a different direction.

Four merge rules that actually hold

• Assign a primary key before you spawn. Every subagent’s output must be keyed to something canonical — a company domain, a document hash, a segment ID. Deduplicating on a name string will merge “Acme Inc” and “Acme, Inc.” roughly never.
• Fix the output schema in the brief, not in the merge. A subagent that returns prose has pushed the parsing cost onto the orchestrator and onto you. A subagent that returns the same five fields every time merges mechanically.
• Require an explicit null. The most valuable finding in a wide research run is often “no public source states this.” If your brief does not ask for that explicitly, the model will fill the gap with something plausible.
• Keep contradictions as contradictions. When two agents return different prices for the same plan, the merge should surface both with their sources, not silently pick one. The disagreement is the finding.

Citation fabrication in agentic research systems is measured, not anecdotal. A 2026 study by Rao, Wong and Callison-Burch (arXiv:2604.03173, published 3 April 2026) evaluated 10 models and agents across 53,090 URLs on DRBench, and 3 models across 168,021 URLs on ExpertQA. It found 3 to 13% of cited URLs were outright fabricated, meaning no Wayback Machine record existed for them at all, and 5 to 18% were non-resolving overall, with rates varying by domain from 5.4% on business-domain queries up to 11.4% on theology.

Those numbers describe the models and agents that study evaluated. They are not a measurement of Kimi K3, of Agent Swarm, or of any Moonshot system, and nobody should read them that way. What they establish is that the failure mode is real, quantified, and large enough to matter at research volume — which is the reason to build a verification step into the workflow regardless of which vendor you run it on.

Two findings from that paper change how you sequence the workflow. The first is that deep-research agents generate more citations per query than plain search-augmented models but hallucinate at a higher rate — so a wider fan-out does not automatically buy more reliable sourcing, it can simply produce more total fabrications to catch. The second is the useful one: self-correction, where the model re-checks its own citations against a live-URL tool, reduced non-resolving citation rates by between 6 and 79 times, down to under 1%, though how well it worked depended on the model’s own tool-use competence.

Operationally that means the automated pass goes before the human one, always. Fetch every cited URL, record the status code and the fetched title, and flag any citation that fails to resolve or whose title bears no relation to the claim it supports. That pass is cheap and mechanical. A senior reviewer reading 300 findings and manually clicking links is neither, and it burns exactly the attention you need them to spend on judgement. The same discipline applies to any always-on agent you deploy — we walk through it in the context of an always-on competitor-monitoring agent.

Market research already has an established answer to the question “what do we do when independent sources disagree,” and it predates agents by decades. It is triangulation: cross-checking findings across independent sources and methods, and treating agreement between independently-sourced findings as the reliability signal, rather than agreement inside a single source. The methodology literature names four types, and each maps onto a different thing a Swarm run can get wrong.

The triangulation literature also ties recency directly to reliability, noting that markets evolve quickly and that periodic data updates keep estimations current and maintain the integrity of ongoing reports. That is the precedent for adding a recency weight to the review stage. A finding a subagent pulled from a cached or undated page should be down-weighted against one confirmed on a source dated inside the research window, and a pricing figure with no visible date should not survive to the brief at all. Agents are extremely good at retrieving something that was true, which is not the same thing as retrieving something that is.

That framing, from Capacity Interactive’s February 2026 summary of the Marketing AI Industry Council’s talent report, is the correct way to read the review step economically. The human in a Swarm research workflow is not there to catch typos. They are there to do the three things the fan-out structurally cannot: adjudicate contradictions, apply a framework, and decide what the client should do. Everything mechanical — dedup, liveness checks, schema validation — should be automated out of their path before they open the document. If you are thinking about how that reshapes delivery roles rather than just one project, we looked at how agencies are restructuring delivery around agent swarms.

Swarm is gated to paid membership tiers. The help centre names Moderato, Allegretto and Allegro members; a fourth tier, Vivace, appears on the vendor’s GitHub-hosted mirror of the same page. The help centre also states that Swarm tasks consume relatively high credit, roughly several times that of a regular Agent task, depending on task complexity. It publishes no fixed per-agent or per-task credit price.

Because the vendor publishes no per-agent credit price, the only honest way to size the spend is to model the same fan-out on the K3 API, where the rates are published. The table below is our model, not Swarm credit pricing, and it is arithmetic rather than a measurement. It uses Moonshot’s standard list API rates — $3.00 per 1M cache-miss input tokens and $15.00 per 1M output tokens, with output billing including the model’s reasoning trace. Cache-hit input, at $0.30 per 1M on the same standard list, is excluded deliberately: subagents on a wide fan-out mostly read pages nobody has read yet.

The per-cell formula is stated and applied identically on every row. Each subagent is budgeted 120,000 cache-miss input tokens and 20,000 output tokens including reasoning. Subagent inference is (agents × 120,000 ÷ 1,000,000 × $3.00) plus (agents × 20,000 ÷ 1,000,000 × $15.00). The merge pass reads every subagent’s output as input and emits a fixed 15,000-token brief regardless of width, so it is (agents × 20,000 ÷ 1,000,000 × $3.00) plus (15,000 ÷ 1,000,000 × $15.00). Substitute your own token budgets; the shape does not change.

The finding in that table is the flat right-hand column. Cost per research slice barely moves between a 12-agent run and a 300-agent one — $0.74 down to $0.72 — because there is no volume discount hiding anywhere in the arithmetic. Fan-out width is very nearly a pure multiplier on spend. A 300-wide run does not cost you more per unit of research, it just costs you 24 times as much research, and the only question worth asking is whether you actually needed 300 slices.

Anthropic’s framing of when the multiplier is justified applies cleanly here: multi-agent architectures pay for themselves when the value of the task is high enough to pay for the increased performance. A single-competitor price check does not justify a 100-agent fan-out. A full landscape scan across dozens of players, billed as a strategic deliverable, plausibly does. The second thing the table shows is that the merge pass does not shrink into insignificance as you widen. Its share of the bill drifts down, from 11% of the 12-agent run to 8% of the 300-agent one, but in dollars it goes from under a dollar to more than eighteen — about nineteen times more expensive. Merge is not a rounding error at width.

Put the pieces in order and the workflow has three gates, each of which stops work that would otherwise be wasted downstream. Nothing here is exotic. The discipline is in refusing to skip a gate because the fan-out looked like it went well.

Before the run

• Write the research question as a single sentence, then write the slice list. If you cannot enumerate the slices, the question is not decomposed yet and Swarm is the wrong tool for it today.
• Fix the output schema. Same fields, same types, every subagent, an explicit null allowed for every field.
• Set the width against your tier’s published cap and your tool-call budget, not against the 300 ceiling.

During the run

• Watch the tool-call count against the documented ceiling of more than 4,000 per task. Budget calls per agent rather than assuming agent count is the binding constraint — 40 agents at 50 calls each already spends about half the budget.
• Sample two or three subagent outputs early. If they are returning prose instead of your schema, kill it and fix the brief — the merge cost of unstructured output is worse than the restart cost.

After the run

• Automated pass first: dedupe on the primary key, validate the schema, resolve every cited URL, flag the failures.
• Human pass second: adjudicate contradictions, apply recency weighting, spot-audit a sample of surviving citations, choose the interpretive frame.
• Record what the run cost and what it produced. The only way to calibrate width is a few runs of your own data.

Two forward-looking things follow from the constraints above. The first is that width should be planned against your slice list, your tier figure and your tool-call budget rather than against the headline ceiling. We would size a first run to the number of genuinely independent slices you can enumerate, record what it cost and what it returned, and let your own numbers set the width for the next one. The 300 figure is a documented maximum; the tier figure and the tool-call budget are what will actually bind.

The second is that the leverage moves, over time, from the fan-out to the merge. Once orchestrators are trained specifically against parallelism quality — which is what Moonshot’s documented three-dimensional reward function is aimed at — spawning good subagent briefs becomes commodity capability that every vendor ships. What will still be scarce is a repeatable, auditable reconciliation process with a named human at the end of it, because that is the part a model cannot own on your behalf. Agencies that treat Swarm as a speed upgrade will get faster research of the same quality. The ones that build the merge layer get research nobody else can defend. If you want the wider capability picture beyond orchestration, we covered the rest of the surface in K3’s underused capabilities, and there is a practical adoption precedent in a marketing agency’s real MCP rollout case study. Teams that want the workflow built into their own stack usually start with our AI and digital transformation engagements, or with agentic SEO and research operations when the output feeds content and search work.