# Select patterns by the work, not by a fixed recipe

Keep the dependency graph acyclic; bounded feedback loops sit around execution
and validation, creating explicit correction attempts rather than cyclic task
prerequisites. A single plan may combine these patterns. The parent remains the
orchestrator and final acceptance owner in every pattern below.

| Pattern | Use when | Required control |
| --- | --- | --- |
| Sequential pipeline | A task consumes an earlier result | Dispatch only after prerequisite acceptance; pass its artifact/interface evidence. |
| Parallel fan-out/fan-in | Tasks are independent | Disjoint ownership or isolated worktrees; explicit integration owner. |
| Hybrid dependency graph | Only some tasks are independent | Recompute ready work after acceptance; do not hold all lanes behind an unrelated slow task. |
| Feedback loop | Concrete validation finds fixable defects | Bounded correction rounds, exact findings, no-progress escalation. |
| Hierarchical ownership | Several subsystems need distinct owners | Parent partitions tasks; workers do not spawn further agents. Add sub-managers only after explicit user approval and a defined protocol. |
| Collaborative experts | A contract needs competing expertise | Read-only CLI forks exchange evidence through parent-authored artifacts; parent resolves disagreements. No invented direct messaging. |
| Conditional routing | Results determine the next assignment | Parent evaluates observed results; Sai may recommend model fit, not decide correctness or termination. |
| Competitive ensemble | Independent alternatives earn their cost | Explicitly budget duplicate work; isolated output/worktrees; parent selects using runnable criteria. Never merge incompatible alternatives blindly. |
| Event-driven | A completion or failure unlocks work | Use actual host completion events, or documented status/revisit steps. Raw CLI forks do not inherit subagent notifications. |
| Goal-driven loop | The goal is fixed but near-term steps are uncertain | Replan affected tasks within approved scope and limits; stop on ambiguity or budget boundary. |
| Human-gated | Scope, spend, destructive action, publication, or unresolved product decisions need approval | Pause only affected work; record the decision and authorized next action. |
| Blackboard | Workers need durable shared knowledge | Parent-owned board and per-worker reports; shared source of truth, no concurrent edits to one control file. |

## Advanced cases

Load/use these only when the plan needs them; they are not defaults:

- **Speculation:** explicit user-approved wasted-work budget, isolated edits, and
  a gate preventing integration until assumptions are validated.
- **Map-reduce:** immutable partition inputs, distinct output paths, and a
  reducer assignment with completeness/deduplication checks.
- **Swarm/market allocation:** do not improvise claims, bidding, or shared queue
  ownership with files. This skill uses parent-assigned tasks; a different
  worker-claim protocol needs separate design and user approval.
- **Recursive decomposition:** the parent may split tasks at checkable seams;
  nested process spawning stays prohibited unless explicitly redesigned.
- **Rolling-wave planning:** refine near-term execution detail without changing
  agreed outcomes or marking uncertain future work ready.
- **Redundant execution:** treat backups as paid independent attempts with
  exclusive workspaces, then choose one result; cancel only with process evidence.
- **Adversarial verification:** give a read-only CLI fork explicit failure
  hypotheses and the exact diff/checks; the parent verifies its findings.
- **Compensation:** preserve partial diffs and define reversible actions before
  risky mutation. Never use `git reset --hard`, discard user work, or claim CLI
  cancellation automatically reverses effects.
- **Continuous optimization:** require a measurable target and explicit stopping
  budget. Do not turn an implemented plan into open-ended improvements.