Implement the Six Core Orchestration Patterns
Worker pool, pipeline, supervisor-worker, adversarial, fork-join, resume chain - build the reusable orchestration patterns every serious multi-agent system converges on.
The route
4 steps to Done
- 01
Build the shared lifecycle infrastructure
Six patterns, one chassis: registration, state, delivery, cleanup.
Preview prompt + verify gate ▾ Hide ▴
Implement the agent lifecycle layer all patterns share. Registration: every dispatched child gets an id, a state (foreground/background/completed/failed/cancelled), and its own cancellation scope - a child's abort control must be independent so cancelling the parent's current step does not kill background workers. Delivery: completed children enqueue their report through one notification path that inserts it into the parent's next turn as visible content - this is the only way results 'exist'. Promotion: a foreground child races its next-step promise against a background signal; when promoted, execution restarts in background mode and the parent receives a task id instead of blocking. Transcripts: persist every child's messages incrementally (an append-only chain keyed by message ids) - this enables resume and post-hoc debugging. Cleanup: a single finally-path releasing everything a child acquired (connections, temp files, watchers, tasks) on every exit route.
- ✓ Child abort scopes independent of the parent's
- ✓ Reports arrive in the parent's next turn, verified
- ✓ Cleanup runs on normal, error, and cancel paths (tested)
- 02
Implement fan-out patterns: worker pool and fork-join
Parallelism is the payoff; delivery discipline is the price.
Preview prompt + verify gate ▾ Hide ▴
Build the two fan-out patterns on the chassis. WORKER POOL: dispatch N same-type children in a single turn, each with an independent slice of the work (a checklist the orchestrator prompt enforces: disjoint scopes, uniform report format); collect reports as they deliver; the parent merges once all arrive. FORK-JOIN: the same shape but with fork-mode dispatch (inherited context) for splittable research - the join step is a parent turn that receives all reports and synthesizes; make the join robust to partial failure (a worker that failed delivers a failure report, and the join proceeds with N-1 plus a note, rather than hanging forever). Both patterns need timeout policy per child and a cap on concurrent children. Test with a real task: four workers investigating four modules, one deliberately failing.
- ✓ Single-turn parallel dispatch with disjoint work slices
- ✓ Join proceeds sensibly on partial failure
- ✓ Per-child timeout and concurrency cap enforced
- 03
Implement sequential and hierarchical patterns
Pipeline hand-offs and supervisor delegation live on explicit messages.
Preview prompt + verify gate ▾ Hide ▴
Build the coordination-heavy patterns. PIPELINE: stage A's report becomes stage B's dispatch input (explore -> plan -> implement); enforce a typed hand-off (each stage's output format is the next stage's expected input) and let the parent validate between stages rather than piping blindly. SUPERVISOR-WORKER: a lead agent decomposes the goal, dispatches workers with scoped tasks, monitors reports, and re-plans - give the supervisor explicit communication rules in its prompt ('writing text does not notify workers; use the send-message tool - only delivered messages exist') because implicit communication is the number-one multi-agent failure. RESUME CHAIN: follow-up work addressed to a completed agent automatically resumes it from its persisted transcript instead of starting cold - detect the stopped state, rehydrate messages, append the new directive. Test each with an end-to-end demo task and inspect the transcripts.
- ✓ Stage outputs validated before feeding the next stage
- ✓ Supervisor prompt names the delivery tool as the only channel
- ✓ Resume rehydrates from transcript and completes
- 04
Implement the adversarial pattern and harden the whole
Verification pressure plus leak-free operation makes it production-grade.
Preview prompt + verify gate ▾ Hide ▴
Add ADVERSARIAL: after an implementer reports done, dispatch an edit-forbidden verifier (see the adversarial-verification flow for its full construction) whose PASS/FAIL verdict gates completion; findings loop back to the implementer. Then harden everything: chaos-test the lifecycle by killing the parent mid-pattern for each of the six patterns and asserting zero orphans (processes, temp files, connections, dangling transcripts) - the cleanup path from step 1 must hold under every pattern's failure geometry; add observability (per-agent trace ids, pattern-level timing, cost per pattern run) so production issues are diagnosable; and write the one-page pattern selection guide: pool for homogeneous breadth, fork-join for splittable research, pipeline for staged transformation, supervisor for dynamic decomposition, adversarial for completion gates, resume for follow-ups - encoded into the orchestrator's prompt.
- ✓ Adversarial verdict gates completion end-to-end
- ✓ Kill-tests show zero orphaned resources per pattern
- ✓ Selection guide lives in the orchestrator prompt
Research-backed