Roles and reasoning effort
Start a bounded delivery with one lead who also integrates and two or three workers owning separable results. This is a starting shape, not a permanent cap or a reason to interrupt existing owners. Widen it after delivery exposes a bottleneck that another worker can remove.
Planner and tracker are responsibilities, not required extra panes. Keep the user's existing division of authority; Clankie can fill the lead role without becoming another supervisor above it.
| Role | Owns | Useful wake |
|---|---|---|
| Lead | Priorities, ownership conflicts, shared integration and delivery decisions | A decision or integration needs action |
| Planner | Bounded issues, dependencies and inspectable acceptance criteria | Intent changes, a dependency changes or the ready queue needs work |
| Tracker | Missing evidence, stale handoffs and claim/result discrepancies | New evidence or a delivery checkpoint needs reconciliation |
| Worker | Implementation, checks, capture and direct publication of an owned result | Work toward that deliverable |
Planner proposes work through the dispatcher. Tracker surfaces actionable gaps to the owner; it is not a mandatory relay, a second verifier of every result or another dispatch authority. Turnover and process recovery are bounded assignments, not permanent reporting duties. End a role's turn when nothing needs judgment.
Effort follows the task
These are starting defaults for the user's Astra swarm, not a measured optimum or a mapping between different providers' effort scales. Verify supported settings in the active harness. Explicit user settings take precedence.
| Work | Default effort | Escalation |
|---|---|---|
| Lead | high | xhigh for difficult shared integration or consequential conflicting evidence |
| Planner | high | medium for routine queue maintenance; xhigh for a hard design/dependency problem |
| Tracker | medium | high for disputed evidence or complex retirement/process recovery |
| Implementation, art, modeling, mocap or capture | medium | high for difficult state, networking, deformation, transforms or pipeline diagnosis |
| Bounded technical review | high | xhigh for a reproduced difficult failure that remains unresolved |
| Mechanical uploads, links and captions on inspected evidence | low | medium when interpretation or reconciliation is needed |
Reserve xhigh/max for a named difficulty, not seniority or time spent waiting for a render. Keep acceptance checks unchanged at every effort. After resolving the difficult part, return to the routine default. Compare total tokens through acceptance, usable artifacts, rework and missed defects over a wave.
Configure the actual harness; prose asking for an effort is not a setting. For a new Codex pane, the CLI supports an explicit launch override:
herdr agent start worker --kind codex --pane <available-pane> -- -c 'model_reasoning_effort="medium"'
For an existing pane, use its supported configuration path at a safe turn boundary
and verify the resulting setting; do not interrupt active work or claim a queued
request changed it. Check the scope: Codex's /model picker can persist global
defaults, and the next-turn settings API requires a reachable app-server endpoint.
Clankie's fleet notes express routing preferences; they do
not configure workers. Its service effort setting governs its own captain, not
external Codex or Claude seats. Inspect clankie help and current settings before
changing either. Do not change a user's global model default to tune one swarm.