Skip to main content

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.

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

Plan mode

Multi-step plans where individual steps may fan out to sub-agents.

Command approval

Pre-approving patterns so sub-agents don’t all queue at the same gate.