> ## Documentation Index > Fetch the complete documentation index at: https://www.rumus.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Sub-agents > When the agent spawns independent workers in parallel — and how their results flow back into your conversation. For jobs with independent pieces, the agent can spawn **sub-agents**: child agents that run in parallel, each with its own scratch space, working on a separate slice of the task. They report results back into the main conversation, so you keep one thread for the whole job. Sub-agents are **agent-initiated** — the agent decides when fanning out is faster than serial work. There's no UI button to spawn one yourself. ## When the agent fans out Typical patterns the agent recognizes as parallelizable: * **Search across many places** — "find any service config that mentions `OLD_HOST`" spawned across multiple directories at once. * **Independent investigations** — three different theories about why something failed, explored in parallel and the best one wins. * **Per-host work** — when a task naturally splits across hosts in a fleet, each host can become a sub-agent. If the work has dependencies (B has to wait for A), the agent runs them sequentially — sub-agents are for the parts that genuinely don't depend on each other. ## What a sub-agent has access to A sub-agent inherits most of the parent's tools: * ✅ Run command, read file, write file, edit file * ✅ Web search and web fetch * ✅ MCP tools you've configured * ❌ Spawn its own sub-agents (no recursion) * ❌ Create plans (planning stays at the parent level) Each sub-agent has a **5-minute timeout**. If a worker is taking longer than that, the parent abandons it and the missing result is reflected in the final answer. ## How sub-agents render in the sidebar You don't see a separate window per sub-agent. Instead, the parent conversation gets a **subtask block** that shows: * The sub-agent's mission ("search `/etc` for old IP references"). * Its tool calls as they happen (forwarded from the child to the parent UI). * Its final result. Multiple subtask blocks can be in flight at once — they update independently, and the parent agent waits for all of them before continuing. ## Approval flows from sub-agents If a sub-agent's tool call needs approval — say it wants to run a non-whitelisted command — that approval request **bubbles up to the parent conversation**. You answer once; the sub-agent gets the answer back and continues. This means you don't have to babysit each child individually. Everything funnels into the main approval flow you're already watching. ## Limits and gotchas * **No user-triggered spawn.** You can't manually say "fan this out" — the agent decides. If you want the same effect explicitly, structure your prompt as a list of independent sub-tasks: *"Investigate these in parallel: A, B, C."* The agent will often spawn workers from that. * **No nesting.** Sub-agents can't spawn their own sub-agents. Parallel breadth, not arbitrary depth. * **No shared state between siblings.** Each sub-agent has its own scratch context. They don't talk to each other; they just report up to the parent. * **5-minute hard cap per worker.** If the work might take longer, give the agent a smaller scope so each piece fits. ## When fan-out helps and when it doesn't Sub-agents shine when: * The pieces are truly independent. * You'd otherwise wait sequentially. * The work is bounded — finite searches, finite hosts. Skip them (and just let the parent agent work serially) when: * One piece's result feeds the next. * The whole job is fast enough that overhead would dominate. The agent makes that call automatically — but knowing the trade-off helps you write prompts that fit. ## Next steps Multi-step plans where individual steps may fan out to sub-agents. Pre-approving patterns so sub-agents don't all queue at the same gate.