Spokes.wiki Search About
Defined Term mechanism updated Fri Aug 07 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Agent orchestration (orchestrator-worker fan-out)

The pattern of a main agent decomposing a task and fanning out to parallel subagents, then collecting/verifying their results — the recurring agentic-execution shape across this wiki. Introduced by orchestration-mode.

The pattern

  • Three tiers: orchestrator (main loop) → a fan-out tool → many parallel subagents (each a small nested agent loop with its own tools), results collected and often cross-checked.
  • Standing consent lets the orchestrator fan out by default for substantive work rather than asking each time; mid-conversation system messages toggle/steer it while preserving the prompt cache (a claude-opus-4-8 capability).
  • Quality moves: adversarial verification (a second wave checks the first), a completeness critic, multi-phase sequencing (understand → design → implement → review). The same two-agent implementer/egoless-reviewer pattern doubles as a safety gate (agent-guardrails).

Instances in this wiki

  • orchestration-mode — the worked API example (Workflow tool → ≤10 subagents).
  • claude-managed-agents — ships agent.yaml + depth-1 leaf-worker subagents and a handoff_request event loop.
  • gbrain — runs subagents as a durable, crash-safe Minions job queue.
  • agentsys — 49 single-responsibility agents behind phase-gated pipelines and multi-agent /audit-project review.
  • agent-kanban — a supervised, collaborative variant: a shared board with agent identity where a leader agent delegates and agents review each other’s PRs, humans watching.
  • orchestrate-100-agents-claude-code — the largest-scale instance (100+ agents) and a distinct flavor: headless mode (claude -p), i.e. many stateless one-shot sessions fanned out with strong task isolation and self-verification, instead of nested in-process subagent loops. No shared state — isolation prevents interference (a context-rot rot-avoidance move); scoped to well-defined (reversible) work like refactoring.
  • claude-security-plugin — Anthropic’s own shipped instance: a six-phase dynamic-workflow scanner (Inventory→Threat-model→Research→Sweep→Panel→Adversarial) with model-tiered roles (Opus-class orchestrator, Sonnet-class cartographer/explorer, session-model researchers/verifiers) and a 2-of-3 verifier quorum whose tally is computed in Python, not asserted by the model — adversarial verification hardened into a mechanical gate.
  • virtual-biotech — the largest instance by two orders of magnitude (tens of thousands of agents; 37,000 on one clinical-trial task) and the one that breaks the shape: agents are differentiated by data source and org role under a CSO agent and pharma-style divisions, and the claimed benefit is debate between them rather than coverage or speed. Its author’s conclusion — stop tuning agents, tune the environment — is the first argument in this wiki for retiring the orchestrator’s specification at scale. Single T3 talk, no numbers on the comparison (stanford-virtual-biotech-37000-agents).
  • auto-company — fan-out where the roster is chosen by a state file: each cycle picks 2–5 of 14 expert personas based on the “Next Action” line in memories/consensus.md, then instantiates them as subagents. The orchestrator doesn’t decide the squad from its read of the task; the previous cycle’s written handoff does — orchestration decisions persisted as memory rather than held in an orchestrator’s context.

Parallelism for redundancy, not just decomposition (tail-control-agentic-workflows)

Fan-out here splits different subtasks across subagents (decomposition). A reliability variant fans out the same call as redundant racing attempts and takes the first valid result — halving p99 latency to beat a deadline (tail-control-agentic-workflows). Same primitive (parallel calls), opposite purpose: decomposition buys coverage, racing buys a shorter tail. Hedging the redundant attempt to a different model/provider keeps it from double-spending a shared token quota.

The declarative counterpart: graph workflows (graph-based-agent-workflow)

Fan-out is imperative — a main agent spawns subagents at runtime. A graph-based workflow (ADK Go 2.0) is the declarative sibling: the branch/join/loop/route structure is named up front as nodes+edges and a scheduler runs it, owning retries, concurrency caps, isolation, and durable pause/resume. They compose (an agent node can itself fan out), and ADK’s “a graph is an agent” even collapses the two into one runtime — orchestration stops being a separate layer above the agent and becomes the agent’s own execution model.

Connections

This is the execution-time counterpart to the authoring-time discipline of spec-driven-development, and the “automate” end of the augment→automate axis in synthesis — work that a human or single agent once did serially is fanned out and checked by many agents at once. When packaged as a product with task selection, gates, CI and delivery wrapped around the model, it becomes an agentic-coding-harness.

orchestration-mode · claude-managed-agents · gbrain · agentsys · agent-kanban · orchestrate-100-agents-claude-code · virtual-biotech · agent-environment-design · tail-control-agentic-workflows · agentic-coding-harness · agent-guardrails · claude-opus-4-8 · spec-driven-development · graph-based-agent-workflow · adk-go-2