Delegating to helpers

Understand delegation, parallel work, resource limits and how results return.

Delegation gives one agent a bounded job to perform for another. The parent conversation stays focused on the overall result, while a specialist uses its own instructions and capabilities. Use it when a task benefits from a distinct role or from independent work that can run concurrently.

Define the handoff

A good delegated brief includes the exact question, the input location, the permitted changes, and the expected answer. For example:

Review the installation chapter against the current app source.
Return mismatches with source filenames and proposed wording.
Do not modify code or publish the document.

Avoid splitting work that requires two agents to rewrite the same file at once. Independent ownership is easier to review and combine.

Enable and scope delegation

For the built-in coordinator, open its Subagents settings. For a custom agent, enable delegation in its abilities and select the allowed targets. Permission choices determine whether a dispatch asks, is denied, or is allowed.

Local and shared-agent permissions are separate. A shared agent belongs to a different execution context and may require review even when a local specialist is allowed automatically. Check the actual settings rather than assuming one permission applies to every target.

What a worker receives

A worker uses the selected agent's model, instructions, tools, and working context. A target without its own folder can inherit the parent's job folder. The worker does not receive unlimited authority merely because the parent asked for help.

Workers report back to the parent. They do not recursively spawn arbitrary teams or open the normal direct clarification flow. If input is missing, the result should explain that need so the parent can resolve it.

Dispatch patterns

spawn_agent is the delegation operation. Continuation uses the returned session_id; background execution uses the supported background option. Multiple calls in a wave share the applicable approval and admission path, while each task still needs a clear outcome.

Artifacts shared by a worker can appear in the parent chat. The parent should verify them before claiming the complete user objective is finished.

Bound the work

Delegation settings include output length, turns, elapsed time, and concurrency. Current defaults include 24 delegate turns and a 900-second elapsed-time budget. Installed profiles or explicit configuration can differ.

A budget limits execution; it does not guarantee completion. A worker that reaches a limit should return a partial result with the remaining work, not be treated as successful simply because it stopped.

Local models and memory

Several requests using the same resident model can share that model, subject to batching and memory limits. A specialist requiring a different local model introduces a model-residency decision. Mellow can swap models or refuse a run that cannot fit safely.

Inspect Swap local models for subagents, Check memory before delegating, and the concurrency controls before increasing parallelism. A configured maximum is a ceiling; the runtime can admit fewer workers because of memory pressure or other active work.

Cloud/provider workers have different resource constraints, but still depend on service availability, authentication, and rate limits. Moving inference to a provider does not make a remote filesystem available.

Review delegated work

Open delegation history or the worker conversation to inspect the underlying run. Compare the brief with the delivered result. For file work, check the actual file and relevant validation. For research, inspect cited sources. Preserve a worker's qualification when summarizing its answer.

Troubleshooting

Media, browser, and computer-use subagents have additional setup requirements. See their dedicated references before assuming a generic delegation test validates those capabilities.