Multi-Agent Topologies
The shapes agents take when they work together, single agent, orchestrator with parallel workers, sequential pipeline, debate, handoff. Multiple agents mainly buy you more tokens and parallel context windows, so they pay off only when the task is wide, valuable, and parallelizable.
A multi-agent system is several LLMs autonomously using tools in a loop, coordinated. The dominant production shape is the orchestrator-worker pattern: a lead agent plans, then spawns subagents that explore different facets in parallel, each with its own context window, before the lead compiles their compressed findings. Other shapes include sequential pipelines (each stage refines the last), fan-out / map-reduce (split, solve in parallel, merge), debate / critique (agents challenge each other to improve answers), and handoff (one agent routes the task to a specialist). Source: Anthropic, https://www.anthropic.com/engineering/built-multi-agent-research-system, 2026-05-31
Why subagents help
"The essence of search is compression." Subagents run in parallel with separate windows, each distilling a corpus down to the few tokens that matter, which sidesteps the attention-budget limit of one agent reading everything. They also enforce separation of concerns: distinct tools, prompts, and trajectories reduce path dependency. Anthropic's research system (Opus lead, Sonnet subagents) beat a single-agent baseline by 90.2% on its internal eval. Source: Anthropic, built-multi-agent-research-system, 2026-05-31
The economics gate
Multi-agent systems win mostly by spending more tokens. In Anthropic's analysis, token usage alone explained ~80% of performance variance on a hard browsing benchmark. The cost is steep: single agents use ~4x the tokens of a chat, multi-agent systems ~15x. So the topology is justified only when the task's value clears that bill, and when the work is genuinely parallel. Source: Anthropic, built-multi-agent-research-system, 2026-05-31
When NOT to go multi-agent
Tasks that need all agents to share one context, or that have tight inter-agent dependencies, are a poor fit, today's agents are not good at real-time coordination and delegation. Most coding work is in this bucket: fewer truly parallelizable subtasks than research. Prefer a single agent (with memory and good tools) until breadth and parallelism actually demand more. Source: Anthropic, built-multi-agent-research-system, 2026-05-31
Kevin's "too many subagents" row is the short operational version of that warning. More workers add merge policy, ownership boundaries, cost caps, cancellation semantics, and result verification. If those are not explicit, the topology is just coordination load with extra transcripts. Source: X/@kevskgs, 2026-03-18
Topology selection
| Topology | Use when | Control requirement |
|---|---|---|
| Single agent | Task is narrow, context must stay coherent, latency matters | strong tools, memory, and verifier |
| Prompt chain / pipeline | Each step transforms the previous result | checkpoints and typed intermediate outputs |
| Router | Inputs naturally fall into specialist categories | reliable classifier and fallback path |
| Parallel fan-out | Independent subtasks can be solved separately | merge/rank/eval step to resolve conflicts |
| Orchestrator-workers | Lead agent must decompose unknown work dynamically | run state, cost cap, worker isolation |
| Evaluator-optimizer | Output can be iteratively judged and improved | explicit rubric and stop condition |
| Remote-agent delegation | Another agent system owns a capability or domain | Agent2Agent (A2A)/API contract, auth, audit boundary |
Anthropic's "Building Effective Agents" names the same workflow families: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Treat these as engineering patterns, not agent personality types. Source: Anthropic, https://www.anthropic.com/engineering/building-effective-agents, 2026-06-19
Observability requirement
Multi-agent systems multiply both capability and ambiguity. A single-agent trace is already hard to inspect; a swarm without Agent Trajectory Evaluation is basically a bonfire with prettier logs.
Before going multi-agent, define:
- run ID and parent/child worker IDs,
- worker instructions and capability scopes,
- per-worker context budget,
- merge policy,
- disagreement handling,
- cost/latency cap,
- artifact ownership,
- cancellation semantics.
That is why Agent Control Plane Architecture matters. Once agents can spawn agents, the product needs fleet state, not only chat state.
Agent Company OS adds a persistent department topology on top of ordinary orchestrator-worker systems: long-running department leads own objectives, route work to the right worker seat, and keep accountability while ephemeral workers execute. This is a better default for recurring company functions than one ad-hoc coordinator per task. Source: X/@DerekNee, 2026-06-25
Orchestrating Kevin's fleet (every agent, not just Cursor)
These patterns are agent-agnostic — they apply across the whole fleet, not one IDE:
- Per-agent spawn mechanisms: Cursor
/orchestrate(recursive agents via the Cursor SDK), Codex and Claude Code native sub-agents / Task tool, and — for any agent — parallel git worktrees + best-of-N (one isolated branch per attempt, then merge/rank the winner; see Git Workflow). - Fleet substrate: Agent Machines is "the home for your agents" — run as many as you want on any model — and Agent Control Plane Architecture is why a swarm needs fleet state, not chat state (run/worker IDs, budgets, merge + cancellation policy).
- One harness across all of them: Cross-Agent Harness Portability keeps Cursor, Codex, Claude Code, OpenClaw, and Hermes on one opinionated preset (skills, rules, identity), so an orchestration choice ports across agents instead of being re-solved per tool.
- The loops the fleet runs: Browser Testing Skills (every feature/fix), Borrowed Intelligence (Drain It into Plans) (drain strong-model plans, execute cheap), The Eval Loop (Slop Is an Output Problem) (gate AI output), The Brain-Agent Loop (answer from compiled knowledge first). Live working set: Active Stack (What to Actually Use).
The topology choice is independent of which agent runs it: pick by task shape + the economics gate, then map it onto whichever agent(s) the fleet has spare.
Relation to the wiki
This is the external-research literature behind Kevin's Recursive Agent Orchestration (recursion as a topology) and Orchestration Variables (the knobs that tune one). The sequencing rule from Observation Precedes Orchestration still binds: wire up observability before you let several agents loose, or you cannot debug the swarm. Heavy prefix reuse across subagents is what makes the caching math survivable.
Timeline
- 2026-06-19 | Added topology-selection matrix, Anthropic workflow-pattern cross-check, and control-plane/trajectory observability requirements. Source: whole-wiki concept review, 2026-06-19
- 2026-06-25 | Added Agent Company OS as the recurring department-lead topology: persistent leads dispatch scoped workers and route proof back into memory. Source: X/@DerekNee, 2026-06-25
- 2026-07-04 | Added Kevin's "too many subagents" row as the compact warning against worker count without explicit ownership, merge, cost, cancellation, and verification boundaries. Source: X/@kevskgs, 2026-03-18
- 2026-05-31 | Page created from Anthropic's multi-agent research-system writeup. Captured the orchestrator-worker pattern and the pipeline/fan-out/debate/handoff catalog, "search is compression," the 90.2% lift, the token economics (80% of variance; 4x and 15x), and the anti-patterns (shared context, tight coupling, most coding). Source: https://www.anthropic.com/engineering/built-multi-agent-research-system, 2026-05-31