# Delegation — capability tiers, roles, token economy

How to spend model capacity in this repo, for **any** agent harness.
Tasks are matched to capability *tiers*, not vendor model names; each
harness maps tiers to its own models (table at the bottom). GOALS says
what to build, CONVENTIONS how to write it — this says who does which
part.

## The dividing line: evidence vs judgment

Cheap models gather evidence; they never make verification claims or
design decisions. The following always stay on the **frontier** tier and
are never delegated downward:

- deciding what to test and the regression scope (VERIFICATION.md)
- interpreting an ambiguous or flaky failure
- viewing screenshots and judging visual quality — aesthetic judgment is
  exactly what small models do badly, and it's load-bearing here
- writing non-trivial Nix (module structure, overlays, cross-cutting
  refactors)
- the final diff review and report

Product calls ("finish vs quarantine", promoting PROPOSED items) sit
above even that: they belong to the human.

## Tiers

| Tier | Best for | Delegate to it? |
|------|----------|-----------------|
| **light** | bulk mechanical: search, summarize, audit sweeps, running the harness | freely — never for judgment |
| **standard** | well-specified scoped edits, routine research | when the spec is already written |
| **frontier** | design, novel code, ambiguous failures, taste | this is the loop's own tier |

Reasoning effort: default moderate; go maximum only for the hardest
calls. A frontier parent may spawn a frontier child for one hard call.
Work above your tier gets returned, not attempted.

## Standing roles

Two mechanical roles exist for any harness that supports subagents
(Claude Code implementations: `.claude/agents/`; other harnesses
implement the same contracts in their own format):

- **scout** (light, read-only): locate where things are defined, map
  which files touch a subsystem, scan build logs / serial output for
  error lines, docs-vs-code drift sweeps. Reports facts with paths and
  line numbers, quotes the minimum snippet, says "not found" plainly —
  never guesses, never recommends.
- **runner** (light, executes): builds, VM boots, screenshot capture,
  the scripted `tools/` checks. Headless and unattended, every wait
  bounded by a timeout. Returns commands, exit codes, wall time, and
  artifact paths — never marks anything passed or verified; the caller
  makes the verification claim.

Use them for pure information-gathering or pure execution instead of
pulling bulk (log files, wide scans) into the main context. When a
result surprises you, spot-check it yourself before building on it —
cheap models are allowed to be wrong about hard things, which is
precisely why they're not allowed to make claims.

## Economy rules

- **Only delegate when writing the spec is cheaper than doing the
  work** — a spawned agent starts cold and must re-derive context. A
  one-file read is cheaper done directly.
- **Brief every child cold; point at the spec, don't restate it.** "The
  spec is in `agent/BACKLOG.md` #NN — implement it" plus only the
  *constraints* (scope files, branch, no-VM, no-push).
- **Match the tier to the task, not the prestige.** An item whose spec
  is already written (exact files, exact fixes) is standard-tier work;
  reserve frontier children for genuine multi-step reasoning. This is
  the single biggest saving.
- The strong model writes the spec, reviews the result, and owns the
  commit.

## Fanning out parallel work (V0/V1, no VM)

When several NEXT items are independent and don't need the VM, spread
them across worktree-isolated subagents in parallel:

- **Disjoint file lanes.** Partition items so no two agents touch the
  same file (map the touched files first). If two items must share a
  file (README, flake.nix, rofi.nix), give both to one agent or keep
  one for yourself.
- **Isolation + you own landing.** Each agent works in an isolated
  worktree, commits to its own branch, and **never pushes or touches
  `main`/`v1`**. You review each diff, cherry-pick onto `main`, and do
  the bookkeeping — a single landing agent can't race itself. Clean up
  worktrees and branches after landing.
- **Lean on scriptable checks as primary evidence.** Where a
  deterministic `tools/` check or `checks.*` guard already proves the
  property, that near-free run *is* the V0/V1 evidence.
- **Batch V2 at the end, once.** Delegated visual/behavioural items come
  back "V2 pending"; collect the landed changes and do **one** VM pass
  covering all of them — the VM render + screenshot review is the most
  expensive step in the loop; amortise it.
- **Re-verify on `main`, but leanly.** After landing, confirm the
  agent's V0/V1 on the merged tree with a targeted build, not a full
  re-run. Trust-but-spot-check scales; blind re-running doesn't.

The judgment list above still holds: *you* review every diff before it
lands.

## Per-harness model mapping

| Tier | Claude Code |
|------|-------------|
| light | `haiku` |
| standard | `sonnet` |
| frontier | the session's top model (`opus` and up) |

Other harnesses: add a column when one is actually used on this repo.