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 type. 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. ## Types There are three subagent types. Every one of them runs in the background: the spawn call returns straight away with an id, and the result reaches you as a notification. Pick one with two questions: **does it need to change anything**, and **what do you want back**? `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. | Type | Changes things? | Gives you back | Tools | When to use | |---|---|---|---|---| | `researcher` | No | Findings | `web_search`, `web_fetch`, `file_read`, `file_list`, `code_search`, `recall`, `skill_execute`, `notify_parent` | Web research, ...