# Task groups and orchestrators ## Pattern **Orchestrator + 2+ workers**, all dispatched from the same PA session. The orchestrator plans, dispatches, collects, integrates. The workers execute in isolation. - **Orchestrator role.** For multi-role software projects: Project Lead. For domain-specific groups: the domain's orchestrator role. Both dispatch as `general-purpose` (see dispatch-envelope § Capability Matrix). - **Workers.** Role-specific — writer, code implementer, librarian, tool-developer, etc. Each gets an 8-section brief from the orchestrator. - **Orchestration accountability.** The orchestrator is responsible for the group's return shape. The PA reads only the orchestrator's final message. ## Depth-2 production posture The dispatch mechanism supports deeper (verified to depth-4). Production posture is **depth-2**: PA → orchestrator → workers. Workers do NOT fan out further. **Why depth-2:** - Observability tax scales linearly with depth. At depth-2 the PA has direct visibility into orchestrator returns; at depth-3 the parent's view of the leaf is doubly summarised. - Coordination overhead scales worse. Multi-tier orchestrators mean recovering from a mid-tier failure requires re-briefing at every level. - Debugging cost is real. Deep chains mean tracing a failure back to root cause traverses multiple opaque summarisation checkpoints. If a genuinely nested problem shape appears (workers each need their own team), lift the sub-team to a sibling orchestrator at depth-2 rather than nesting. ## Per-worker brief Every worker in the group gets its own 8-section brief authored by the orchestrator (or by `dispatch-briefer` on the orchestrator's behalf). Briefs share Context and Trace fields where the workers are all part of the same integration, but Goal / Boundaries / Done-when / Escalation-rule are per-worker. ## Orchestrator return structure Because the PA only sees the orchestrator's final message, the orchestrator's return MUST enumerate each worker's outcome. Minimum shape: ``` ### — orchestrator return **Group status:** success | partial | escalation **Workers:** | Name/role | agentId | Status | Key artefacts | |---|---|---|---| | writer | a-… | success | PR #123, draft-1.md | | librarian | a-… | success | knowledge-graph-updated | **Integration outcome:** **Escalations (if any):** … ``` ## Related - CLAUDE.md.template Bucket 3 rules 5, 6. - `dispatch-envelope.md` — depth findings, subagent-type constraint, MCP shared state hazards. - `delegation-modes.md` — task group as Mode 2. - Operator-side project-lead role definition — the canonical multi-role orchestrator.