Where Kimi Swarm fits among Missions and Workflows — and how to operate it without the foot-guns.
Kimi AgentSwarm is a parallel executor — fast fan-out/fan-in with forensic disk state. It does not ship built-in done-when contracts, adversarial validation, or write isolation between poorly partitioned subagents.
Droid Missions is a full mission system: orchestrator plans features, workers implement sequentially, validators gate milestones, artifacts live in ~/.factory/missions/<uuid>/. Hours to days.
Claude Dynamic Workflows is deterministic JS in a VM — versionable scripts with parallel() up to 16.
The bridge: use AgentSwarm as the parallel execution layer inside a larger orchestrator with proof gates — exactly the loop-engineering pattern: scope → plan → swarm inspect → swarm execute → validator → proof gate.
Think of it like… hiring a temp agency (Kimi Swarm) vs running a formal construction company (Droid Missions) vs following your own scripted checklist (Workflows). The agency is great for parallel surveys and bounded edits; it won't sign the building inspection for you.
| Dimension | Kimi AgentSwarm | Droid Missions | Claude Workflows |
|---|---|---|---|
| Entry | /swarm, tool AgentSwarm | /missions, droid exec --mission | Tool Workflow, /workflows |
| Plan unit | items[] + template | features.json, validation-contract | JS script in VM |
| Validation | Not built-in | Scrutiny + user-testing injected | Depends on script |
| Parallelism | Up to 128, ramp 5+700ms | Sequential features; parallel in validation | parallel() up to 16 |
| State | agents/*/wire.jsonl | ~/.factory/missions/uuid/ | workflows/scripts/*.js |
| User role | Prompt orchestrator | PM of agents | Script author |
Confirmed anti-patterns from RE — and what to do instead.
✗ Read + AgentSwarm same turn → exclusive-deny ✗ Duplicate items[] prompts → runtime rejection ✗ 1 item without resume_agent_ids → validation error ✗ Overlapping coder scopes → write conflicts (not a runtime bug) ✗ kimi swarm → subcommand does not exist ✗ resume_agent_ids as array → must be Record<id, prompt>Recommended operator patterns
# 1 — Read-only repo map (explore profile) /swarm Map this repository with independent subagents. Use subagent_type explore. Do not edit files. Items: architecture, tests, docs, cli, config # 2 — Partitioned execution (coder profile) /swarm Implement bounded units with separate coders. Items: ui, api, tests Each: read first, scoped edits, run proof command, return diff. # 3 — Independent validation (second swarm, explore) /swarm Validate as independent reviewers (explore only). Items: behavior, tests, security, docs Return PASS/FAIL with exact evidence.
Measurable done-when · adversarial independent validation · write isolation for bad partitions · proof without explicit commands in prompt. Wrap swarm inside loop-engineering or Missions-style gates.
Pick a pattern. Copy the prompt skeleton for your next swarm session.