State of practice as of 2026-06-17 · grounded in Tavily research (Anthropic docs, Microsoft taxonomy, production field reports) · the question: why not a shitload of swarm?
One coordinator fans out subtasks; workers don't talk to each other, all coordination flows through the hub.
most deployedauditableFixed sequential stages: A→B→C. Each consumes the prior. Predictable, debuggable.
deterministicKYC / review flows3–8 named peers with persistent direct channels, iterating on a shared artifact. Topology fixed at design time.
peer debate~3× costMany peers coordinate via shared state; topology emerges at runtime. Broad exploration, unknown solution path.
35–55% ceilinghard to controlTree of supervisors → sub-supervisors → workers. Recursive decomposition for very large tasks.
latency stacksscales
flowchart TD
O([Orchestrator / script]):::o
O --> W1[worker]:::w
O --> W2[worker]:::w
O --> W3[worker]:::w
W1 --> O
W2 --> O
W3 --> O
classDef o fill:#7c3aed,stroke:#b392f0,color:#fff
classDef w fill:#161b22,stroke:#30363d,color:#e6edf3
flowchart LR
A[security]:::w <--> B[ci-cd]:::w
B <--> C[release]:::w
C <--> A
L([team lead]):::o --- A
L --- B
L --- C
classDef o fill:#7c3aed,stroke:#b392f0,color:#fff
classDef w fill:#161b22,stroke:#30363d,color:#e6edf3
flowchart TD
BB[(shared state)]:::bb
S1[agent]:::w <--> BB
S2[agent]:::w <--> BB
S3[agent]:::w <--> BB
S4[agent]:::w <--> BB
S5[agent]:::w <--> BB
classDef bb fill:#d29922,stroke:#f0c674,color:#000
classDef w fill:#161b22,stroke:#30363d,color:#e6edf3
flowchart LR
I[analyze PR]:::w --> F[fix + rebuild]:::w --> M[merge when green]:::g --> N[next tree]:::w
classDef w fill:#161b22,stroke:#30363d,color:#e6edf3
classDef g fill:#238636,stroke:#3fb950,color:#fff
| Primitive | Topology | Coordinates via | Agents talk? | Default agent | Cost | Use when |
|---|---|---|---|---|---|---|
| Agent tool (single) | 🎯 Orchestrator–Worker | parent collects | No (star) | ork:* if named | low | Independent tasks, dispatch & check later |
| Subagent (YAML) | ➡️ Pipeline | locked config | No | pinned | predictable | Repeatable workflows (review, tests) |
| Workflow tool ← this session | 🎯+➡️ Orchestrator + Pipeline | the JS script | No — return data | generic (pass agentType for ork:*) | cheap | Deterministic fan-out over a work-list (11 PRs → 11 readers) |
| Agent Teams | 🕸️ Mesh / 🐝 Swarm | mailbox + shared task list | Yes (SendMessage) | ork:* named | ~3× (every msg = round trip) | Dependent tasks needing peer debate |
| ork:swarm-migrate | 🎯 Orchestrator–Worker | coordinator + ledger | No | per-repo | scales | Same change across N repos |
Self-reported production success rates (unconstrained tasks, 2026 field reports). Higher control = higher reliability.
Caveat: these are directional figures from practitioner reports, not a controlled benchmark. The ordering is the robust signal, not the exact %.
GitHub merges to a shared lockfile are width-1: branch protection forces one-at-a-time. 50 agents can't merge 5 PRs to one tree at once.
TS6 tsconfig, biome one-liner, mirror syncs — each smaller than the overhead of spawning+coordinating an agent for it.
Workflow's agent() defaulted to generic readers, not ork:* personas — the real, fixable gap. Pass agentType:'ork:…' to wire the fleet.
11 PRs → 11 parallel readers (orchestrator-worker) + main-thread execution = the production-standard shape, not a swarm shortfall.
OrchestKit has the personas and the team/workflow primitives — but no general goal → decompose → assign specialist → coordinate auto-router. Every fan-out is hand-designed. Coordination is either script-mediated (cheap, no peer talk) or team-mesh (peer talk, ~3× cost), with no smart selector choosing between them or wiring ork:* in by default.
Sources (2026): code.claude.com/docs/agent-teams · cloudzero.com/blog/claude-code-agents · gurusup.com (5-pattern taxonomy) · truefoundry / tensoria (framework benchmarks) · r/AI_Agents production field report (swarm ceiling).