delegate

Delegate

Use sub-agents when they can do focused work in parallel while the parent keeps architectural judgment, integration, and final verification.

Keep vs Delegate

Keep in the parent:

• Understanding the user's actual request and constraints
• Architecture, security, product, and release-risk decisions
• Cross-module integration
• Final review, test interpretation, and user-facing summary

Delegate to sub-agents:

• Read-only exploration over a bounded file set
• Mechanical edits with a clear file ownership boundary
• Focused test or lint runs
• Boilerplate generation from an explicit spec
• Independent checks that can run while parent work continues

Do not delegate tiny one-step tasks, ambiguous product decisions, destructive operations without a clear acceptance criterion, or final verification.

Launch Focused Work

Use agent for a focused child run. Launch independent children together so they can run in parallel.

Prefer provider-neutral model_strength over hardcoded model ids. Children inherit the active model by default (model_strength: "same"), including type: "explore", so pass model_strength: "faster" explicitly to get the cheaper same-family sibling for read-only exploration:

{
  "name": "config_audit",
  "prompt": "Inspect crates/tui/src/config.rs and crates/tui/src/settings.rs for duplicate model-default logic. Return file/line findings only; do not edit files.",
  "type": "explore",
  "model_strength": "faster",
  "cwd": "."
}

For code changes, give the child a precise write boundary and tell it not to revert unrelated edits. Keep implementation children capable with model_strength: "same":

{
  "name": "docs_patch",
  "prompt": "Update only docs/configuration.md to document the new [statusline] keys. Match the surrounding style. Do not edit other files.",
  "type": "implement",
  "model_strength": "same",
  "cwd": "."
}

Use fork_context: true only when the child genuinely needs the current conversation prefix. Leave it omitted for fresh, narrower context.

Route the Work

Choose the route per child from agent(action:"roster") (no provider request), not from memory. It lists each role's resolved route and the models you may pick.