Isolated Sub-Agents

13.1. Isolated Sub-Agents — Completely Isolated Child Agents

delegate_task — the foundational mechanism of every form of delegation

delegate_task(goal="...", context="...")

Each subagent receives: a completely fresh conversation (no inheritance of the parent’s history), its own terminal session, and a restricted toolset. Only the final summary returns to the parent agent’s context — all the intermediate tool calls and the child’s reasoning process never make it into the parent’s context window.

Security isolation — the child cannot have permissions the parent doesn’t

Each subagent inherits exactly the toolset the parent has enabled — the model cannot grant a child permissions the parent doesn’t have. Some tools are always blocked for subagents regardless of the parent: delegate_task (no recursion — except for subagents holding the orchestrator role), clarify (must not ask the user back), memory (no writes to the shared MEMORY.md), send_message (no cross-platform side effects), execute_code.

The most important principle: the subagent knows nothing about the parent’s conversation

This is the most common mistake when first using delegation: the subagent starts completely blank — if you hand it “fix the error we just discussed”, the subagent has no idea what that error is. Always pass explicit file paths, error messages, project structure, and specific constraints in the context parameter.

Notes

• Use delegate_task for heavy-reasoning tasks where the intermediate results don’t need to be kept (reviewing a piece of code, searching for a pattern in a codebase) — this is exactly the “zero-context-cost” workload the tool was designed for.
• Always write context as if handing the work to someone completely new to the project — missing context is the number-one cause of subagents going off track.
• For high-quality tasks, don’t forget: the model configuration for subagents is global for the whole session (delegation.model in config.yaml); there is no per-task model parameter — if you need different models for different children in the same batch, this is exactly when you should move to Kanban (13.3), which supports per-task model overrides.