subagent

Subagent orchestration -- spawn background agents to work on tasks in parallel. ## Lifecycle Subagents follow this status flow: `pending` -> `running` -> `completed` / `failed` / `aborted` - **Spawn**: Use `subagent_spawn` with a label, objective, and role. The subagent runs autonomously. - **Mid-run communication**: Subagents can send notifications to the parent via `notify_parent` while still running -- useful for sharing interim findings or signaling that they are blocked. - **Auto-notification**: The parent conversation is automatically notified when a subagent reaches a terminal status (completed/failed/aborted). Do NOT poll `subagent_status`. - **Read output**: Use `subagent_read` after the subagent reaches a terminal status to retrieve its full output. ## Roles Each subagent is spawned with a role that determines its tool access. Choose the most restrictive role that can accomplish the task. `recall` is local information search across memory, the personal knowledge base, past conversations, and workspace files. Use it when a subagent needs prior context that is not already in the prompt. | Role | Tools | When to use | |---|---|---| | `general` | Full tool access | Task genuinely needs unrestricted capabilities (rare -- prefer a specialized role) | | `researcher` | `web_search`, `web_fetch`, `file_read`, `file_list`, `recall`, `notify_parent` | Information gathering, web research, codebase exploration, reading documentation | | `coder` | `bash`, `file_read`, `fil...