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: private page 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: Agent Iteration Loop (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 private page (recursion as a topology) and private page (the knobs that tune one). The sequencing rule from private page 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.
Fold subagents back into one loop
Anthropic's guidance (2026-10) is to delete subagents that do not earn their place. A single agent with skills often beats a multi-agent system, and one customer ran about twice as fast after folding. The split: skills teach how, tools and MCP let the agent act, and subagents are only for parallel work, isolated context, or tasks one agent cannot do. The method is to fold each subagent into the main loop, turn its instructions into skills, expose its actions as tools, and run evals to check quality holds. Anthropic ships a migration kit for it. Source: X/@cherry_mx_reds, 2026-10-24; Source: Claude, "When to fold subagents into your main agent loop"; Source: anthropics/single-agent-loop-kit
As models improve, agent architecture work is more about deleting than adding.
Loops and graphs
A loop lets the agent own the path: you set the goal, brief and bar, and it drafts, checks itself and repeats. A graph is you drawing the steps and routes ahead of time, and its shape is a state machine: each node is a state, and a check at each one sends the work forward or back. Use a loop for one-off work whose path is unknown; use a graph for jobs you repeat, where you want gates the work cannot skip, fixed routes and a visible failure point. Source: X/@shannholmberg, 2026-07-20; Source: X/@hwchase17, 2026-07-20 See Find All Implicit State Machines.
A team of agents rebuilt SQLite in Rust from its 835-page manual and passed a held-out test suite; cost varied 15x with the model mix. Source: X/@cursor_ai, 2026-07-20; Source: X/@badlogicgames, 2026-07-20
A guide to a first team of five agents, one per business function, wired into a self-improving loop in a shared workspace. Source: X/@EXM7777, 2026-07-18
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