# Execution Profiles

An execution profile fixes ownership topology only. It never fixes model tier, reasoning effort, helper missions, helper count, or internal coordination.

## Adaptive

`adaptive` is the default. The phase coordinator may implement directly or appoint a separate implementation owner. Independent review remains required. The coordinator chooses the smallest useful execution shape from current evidence and certified runtime capabilities.

## Orchestrator Callback

`orchestrator-callback` is mandatory when selected:

- the current control thread is orchestrator-only
- each phase uses a separate implementation-owner session and a separate independent review-owner session
- the orchestrator owns Beads, phase transitions, runtime activation, and final integration decisions, but never implementation or review
- each owner receives the concrete run-time orchestrator thread ID and one logical terminal-result identity before launch
- callback targets are never placeholders and never inherited from loop creation
- the orchestrator durably acknowledges each logical terminal result before launching the next owner and replays that acknowledgement response for valid duplicate delivery

Implementation and review owners may create bounded helper subagents as certified capacity permits. They remain accountable for integrating helper evidence and sending their one logical terminal result.

## Evidence-Driven Helper Fanout

All implementation and review stages strongly encourage useful helper subagents:

- first enumerate independent risks, surfaces, or evidence questions
- create one bounded mission per useful independent question
- use at most 20 helper missions in an implementation stage and at most 20 in a review stage
- active concurrency is the smallest of 20, the user's configured limit, certified runtime capacity, and currently available slots
- use waves when useful missions exceed active capacity
- do not assume an undocumented product default such as 6
- do not create filler, duplicate, or conflicting helpers merely to approach the ceiling
- a non-trivial stage using no helpers records why direct work is more effective

Helper missions are generated from evidence, not selected from a permanent persona catalog. Useful mission shapes include codebase reconnaissance, contract tracing, test design, security or race analysis, performance inspection, UX/accessibility criticism, and CI or documentation evidence. These are examples, not required roles.

Keep one mutable-checkout owner. Helpers are read-only by default; mutable helper work requires explicit disjoint ownership. The implementation or review owner integrates all helper results.