# Evidence-Driven Delegation

Delegation is strongly encouraged during implementation and review, but agent count is not a phase gate.

First enumerate independent risks, surfaces, and evidence questions. Create bounded helper missions when parallel investigation, independent criticism, context isolation, specialist tools, or separate ownership materially improves the result. For a non-trivial stage with no helpers, record why direct work is more effective.

## Choosing Delegation

Choose at run time from:

- phase complexity and uncertainty
- number of independent surfaces
- architecture and integration risk
- review independence required
- available concurrency, models, tools, and product modes
- latency, cost, and user constraints

Use at most 20 helper missions per implementation stage and at most 20 per review stage. Effective active concurrency is `min(20, user-configured limit, certified runtime capacity, currently available slots)`. Use waves when useful missions exceed active capacity. Never assume an undocumented product default such as 6.

The stage owner chooses model tier and reasoning effort per mission. A fast bounded inspection may use a lower-cost tier and moderate effort; consequential synthesis or ambiguous architecture may justify the strongest available model and higher effort. Treat these as contextual choices, never fixed mappings.

If the bound harness provides certified native multi-agent orchestration, use it as one execution strategy. Do not add filler, duplicate, or conflicting delegates merely to approach the ceiling. Optional plugins are usable only when the harness adapter reports their exact contract as certified; plugin presence alone is not a capability.

Do not maintain a permanent persona catalog. Generate missions from current phase evidence. Codebase scout, contract tracer, test designer, security/race/performance critic, UX/accessibility critic, and CI/documentation verifier are useful mission shapes, not required roles.

Keep one mutable-checkout owner. Helpers are read-only by default. Any mutable helper mission needs explicit disjoint file or worktree ownership, and the stage owner integrates the results.

For an accepted self-upgrade bootstrap, mutable helper missions remain blocked until the frozen builder adapter is mutation- and recovery-certified and a fresh coordinator proves its installed closure. After that gate, compile broad phases into qualified tracer-bullet leaves. Review each owner branch against its recorded base; do not require one external PR per owner. Admit those reviewed contributions to the one Program integration branch in dependency order.

## Delegate Contract

Every delegation states:

- mission and desired evidence
- allowed mutation scope
- relevant files, commands, or questions
- ownership and callback expectations when applicable
- completion or blocked condition

Require compact evidence-backed results. The implementation or review owner synthesizes helper work and remains accountable for its stage. In `orchestrator-callback`, that owner sends one logical terminal result to the concrete orchestrator thread after integration; valid duplicate delivery receives the same acknowledgement response.

## Execution Summary

Record what actually happened rather than proving compliance with a preset topology:

```json
{
  "execution_profile": "adaptive|orchestrator-callback",
  "strategy": "direct|delegates|sessions|native-multi-agent|hybrid",
  "rationale": "...",
  "delegations": [
    {
      "mission": "...",
      "model": "runtime-selected-or-unknown",
      "effort": "runtime-selected-or-unknown",
      "status": "done|blocked",
      "evidence": ["..."]
    }
  ],
  "adaptations": ["..."]
}
```

Zero delegations is valid only when a non-trivial stage's orchestration brief explains why direct work is more effective.