---
name: coordination-patterns
description: Coordinates role-separated implementation and independent review over existing AMQ peers or supervised pi workers. Use when a task benefits from bounded fan-out, explicit acceptance criteria, fresh-evidence audit, and driver-owned synthesis. Skip when the work is smaller than the coordination overhead.
compatibility: Existing-peer mail needs a verified AMQ roster. Local supervised workers need the pi-amq WorkerRuntime and do not require AMQ binding.
---

# Coordination Patterns

Use this skill for either coordination flavor below. It is advisory: adapt or stop when evidence changes, while preserving role, evidence, and verification boundaries.

## Driver posture

The driver owns decomposition, authority, collection, synthesis, and final acceptance. Workers return bounded candidates and evidence; their prose never completes a task by itself. Prefer a few well-separated workers over broad speculative fan-out. Observe stall facts without inventing a nudge, retry, or cancellation policy.

## Existing-peer mail team

1. Confirm that the needed peers already exist in the AMQ roster. Do not invent or spawn a worker.
2. Give each task one explicit role charter, bounded scope, acceptance criteria, constraints, and expected evidence.
3. Dispatch the task as `kind=todo` through the existing AMQ transport.
4. Require the implementer to report outcome, evidence, unrun checks, and residual risk by replying to the exact task envelope.
5. Re-run decisive checks and inspect the named evidence independently in the driver context.
6. Assign audit to a different context from implementation. The auditor reads the authoritative change and obtains fresh evidence.
7. Record approve/reject by replying in the implementation task thread. That thread is the authorization ledger; a detached status message is not approval.

Read [the current mail-team few-shot](references/today-mail-team.md) when a concrete sequence is useful.

## Supervised worker fan-out

1. Split only independent evidence or implementation packets with explicit acceptance criteria and hard constraints.
2. Pick the narrowest named role: scout maps, worker implements, reviewer audits, oracle resolves ambiguity, and researcher sources evidence. Explicit difficulty or capabilities override role defaults; model selection remains mechanical against the live catalog.
3. Call `spawn_worker` once per bounded packet. Declare role, goal, acceptance, constraints, every budget dimension, and any report/check/approval facts. Use RPC when steering or mid-run interaction is expected; JSON is one-shot.
4. Use `list_workers` for authoritative state, Gate blockers, revision delivery, budget, and stall facts.
5. Use `collect` for candidates and evidence. Collection is an observation; `done` requires every declared Gate fact.
6. Use `revise_contract` for contract changes and `steer` only for conversation. Revisions arrive after generation-correlated `agent_settled` without interrupting in-flight inference.
7. Keep synthesis and final judgment in the driver context. If independent review matters, spawn an auditor with source-based acceptance criteria.

Read [the supervised worker few-shot](references/supervised-worker-fan-out.md) before running a multi-worker sequence.

## Boundary

The runtime exposes atomic facts and verbs, not a workflow engine. Contract, Ledger, Lease/launch, Gate, and Delivery are the five governance domains; `WorkerLaunchAuthority` enforces grants under Lease/launch and a request is never a grant. `blocked` is reserved for the RPC child `wait_for_input` fact with a reason and correlation; natural-language waiting is not inferred, blocked workers do not accrue stalls, and only exact-correlated steer, revision, or peer delivery wakes them. Named roles are Contract-default declarations, not ambient addresses or teams. A worker may message only an exact `message_worker:<workerId-or-role>` directional grant; a role must resolve uniquely, the supervisor waits for the recipient inference boundary, and both endpoint projections share the correlated Ledger fact. The runtime has no peer-topology mutation, automatic retry, nudge, pipeline, scheduling preset, or workflow DSL. Coordination examples do not create runtime policy.