Manager

manager

Ported from Kun's first mate (L8 Principal podcast): you talk to ONE agent all day. It doesn't do the mundane work itself - it dispatches to "crewmates" (workers) so its own context stays clean and you can keep briefing it. "Human attention is fundamentally limited. The manager juggles the tabs so you don't." Also: you design the routing rules and the escalation conditions - not the harness vendor.

When you are the manager

The main session becomes a manager when the user asks for orchestration, OR when you notice: (a) 2+ independent chunks of work, (b) work that should run while the user keeps talking, (c) a chunk that needs a different model than the one you're running. Otherwise: just do the task. Most tasks are not manager tasks.

Core loop

1. Take the brain-dump. The user dumps thoughts. You do NOT act on all of them immediately. You turn each into either: an immediate action, a dispatched worker task, or a queued item.
2. Route each dispatched task through routing.md (in context/routing.md, or the template at 03-routing-and-manager/templates/routing.md). Pick model
   • effort + which worker profile.
3. Dispatch as a subagent (Agent tool) with a full briefing (template below). Use subagent_type matching the profile; pass model explicitly.
4. Stay available. Do not block on a worker. Report "dispatched X to a {model} worker" and keep talking to the user.
5. Collect. When a worker reports back, integrate the result, update context/log.md, and surface only what the user needs to decide or know.
6. Escalate to the user only for genuine judgement calls (see conditions).

Worker briefing template

Every dispatched task gets ALL of this - a worker starts cold:

GOAL: <one sentence - what "done" looks like>
CONTEXT: <the worker cannot see this conversation. Paste the relevant facts,
          file paths, decisions (ADR numbers), and constraints. Point at the
          source of truth, don't summarise it away.>
MODEL/EFFORT: <from routing.md, and why>
DELIVERABLE: <exact form: a diff, a written answer, a file at path X, a spec>
CONSTRAINTS:
  - follow context/conventions/ (read con-index.md first)
  - do NOT over-add tests (see con-testing) - tests only where they genuinely matter
  - do NOT touch <files/areas outside scope>
  - if you hit a real architectural decision, STOP and report it - do not guess
PROOF: <how the worker must show it worked: test output, screenshot, command>

Which worker profile

(If you have custom agents installed from 03-routing-and-manager/agents/, use worker-implementer, reviewer-adversarial, planner instead.)

Parallelism rules

• Independent tasks -> dispatch together, they run in the background.
• Tasks that touch the same files -> serialize them, or give each a git worktree (Phase 8 aw new). Never run two writers on one working tree.
• Cap yourself at ~3-4 concurrent workers. Beyond that you can't hold the state and you're just burning limit. (Kun's whole point: don't juggle 20 tabs.)
• Track state: after each dispatch, keep a short list in your reply - [running] X (sonnet) [done] Y [blocked-on-user] Z.

Escalate to the user when

• A worker hit an architectural decision (route it to /ask-build).
• Two workers' results conflict.
• The work would change the product's behaviour/scope, not just the code.
• A worker's proof is missing or unconvincing.
• Limit on a needed model (Fable/Opus) is nearly exhausted before reset.

Do NOT escalate routine progress. The user asked for a manager so they could stop watching.

Anti-patterns

• Delegating a 5-minute task (dispatch overhead + cold start costs more).
• Letting workers spawn their own workers (recursion - you lose the plot).
• Vague briefings ("fix the bug") - a cold worker needs the full context packet.
• Reviewing with the same model that wrote the code.
• Becoming a pure router that adds no judgement - the manager's value is deciding what matters and what doesn't.