# Delegation modes ## Dispatch-first is the operating posture, not a mode you select Before the three modes below, the posture: **dispatch-first**. The PA's main thread exists for three things only — orchestrating work, keeping the work-trail current (work items, projects, spawn-log, journal, staging), and interacting with the operator. Everything that produces a work product — research, writing, code, analysis, multi-file reads — goes into a dispatch. This is stated unmissably at the top of the PA's CLAUDE.md as the "PA operating mode — dispatch-first" preamble; the modes below are only about HOW to dispatch once you have decided (single subagent vs task group), plus the narrow trivial-inline carve-out. **The produces-a-work-product test.** If the ask produces an artefact the operator or a downstream worker would consume — a draft, a code change, a research finding, a synthesised answer that took reading to build — it is dispatched. Mode 3 (single-threaded) is reserved for work that produces no such artefact: a one-line edit, a single file read, a status answer straight from `pa knowledge`, or a task whose topic sits so close to what you are already doing that a dispatch adds pollution without benefit. "Dispatching costs more than finishing" is a tie-breaker inside that narrow carve-out — never a licence to work inline on anything that produces a work product. **The board moves with every dispatch.** Keeping the work-trail current includes the daily status board (the workspace Status page). Every dispatch is opened with `pa dispatch open`, checkpointed with `pa dispatch stage` and closed with `pa dispatch close`: each call writes the spawn-log record and its board item together, and `pa dispatch open` prints the label to give the dispatch (` [project] slug (d-id)` for RCF work, else `[project] slug (d-id)`). Everything else on the board (status ticks, operator rulings, the on-me list) moves with `pa status patch` in the same turn as the event, and the board is reset at session boot with the day's plan (`pa status set`). It is never hand-edited. See `../work-management/status-board.md` and `../work-management/spawn-log.md`. ## The three modes Three modes. Selection is a choice, not a default — each has a distinct trigger shape. ## Mode 1 — Single subagent **Default for any task the operator hands the PA.** Well-bounded work that fits one worker. Pattern: PA hands intent to `dispatch-briefer` → Briefer produces 8-section brief → PA dispatches target worker with the brief → worker returns → PA reviews and reports. Trigger: - Work fits one role. - The context to load is reasonable but non-trivial (otherwise Mode 3). - The output shape is well-defined. Standards: 8-section brief via `dispatch-briefer` (or direct-authored if the exceptions apply — see `briefing-contract.md`). ## Mode 2 — Task group **For read-heavy parallelisable work, work exceeding the PA's context budget, or a multi-role software project.** Pattern: PA dispatches a Project Lead (or orchestrator role appropriate to the domain) as `general-purpose`. The orchestrator plans the group's shape, dispatches role-workers with per-worker briefs, collects returns, integrates. Trigger: - 2+ workers needed on the same problem. - Work spans multiple roles (writer + code + docs + review). - Fan-out reading (10+ files to survey, docs to catalogue, etc.) that would blow the main-thread context. Constraints (from dispatch-envelope findings): - Orchestrator MUST be `general-purpose` or `claude` — other types lack the Agent tool. - Design for depth-1 or depth-2. Depth-3+ is possible but the observability tax is real. - Structured return from orchestrator must enumerate each child's outcome — the parent only sees the orchestrator's final message. - MCP shared state (Playwright, OAuth-gated) hazards apply to parallel workers. Standards: task-group pattern with per-worker briefs; see `task-groups-and-orchestrators.md`. ## Mode 3 — Single-threaded (do it yourself) **For trivial work, or when context is already burned and dispatching would cost more than finishing.** Trigger: - Genuinely trivial: one-line edit, single file read, status check, quick answer from `pa knowledge`. - The context to load is small (already in main thread). - Dispatching would cost more than executing. - **Topic proximity — the ask sits close enough to what you're already doing that a dispatch would add pollution or confusion without benefit.** Executing inline keeps the thread coherent. ## Topic-differs pollution-prevention Rev 4 Bucket 3 rule 1 addition. Off-topic tasks always dispatch — different subjects in one thread degrade both. **How to tell:** if you'd have to switch mental register (from LI comment drafting to code review, from a scheduling question to a voice-guide edit), the topic differs. If the switch is small (from one sub-question of the same brief to another), the topic is the same. The signal is not size — a trivial off-topic ask still dispatches. A large ask on-topic still executes inline (if context allows). Two axes: size, subject-continuation. Both matter. ## Selection tree (quick reference) ``` Is the ask trivially small AND on-topic? Yes → Mode 3 (single-threaded) No ↓ Does it need multiple roles OR heavy parallel reads OR context-budget breach? Yes → Mode 2 (task group with orchestrator) No ↓ Default → Mode 1 (single subagent via Briefer) ``` ## Related - CLAUDE.md.template Bucket 3 rules 1, 4, 5. - `briefing-contract.md` — the brief pattern all modes use. - `dispatch-envelope.md` — capability and concurrency findings. - `task-groups-and-orchestrators.md` — Mode 2 details.