Skip to content
Flows
Agent Architecture Advanced · 120-180 minutes

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.

Start Route · 4 steps

The route

4 steps to Done

  1. 01

    Build the shared lifecycle infrastructure

    Six patterns, one chassis: registration, state, delivery, cleanup.

    Preview prompt + verify gate ▾

    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)
  2. 02

    Implement fan-out patterns: worker pool and fork-join

    Parallelism is the payoff; delivery discipline is the price.

    Preview prompt + verify gate ▾

    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
  3. 03

    Implement sequential and hierarchical patterns

    Pipeline hand-offs and supervisor delegation live on explicit messages.

    Preview prompt + verify gate ▾

    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
  4. 04

    Implement the adversarial pattern and harden the whole

    Verification pressure plus leak-free operation makes it production-grade.

    Preview prompt + verify gate ▾

    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

Sources behind this flow