Some jobs are naturally repetitive — produce a tailored summary for each company on a list, sweep ten devices for the same condition, or research a question from several angles at once. Subagent Fan-Out lets the agent split the work into pieces and tackle them in parallel instead of one after another. When all the pieces are done, the agent comes back with the results bundled together.Documentation Index
Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
Use this file to discover all available pages before exploring further.
Subagent Fan-Out is available on every agent. There’s nothing to enable — the agent decides on its own when a given job is a good fit for fanning out.
When It Helps
Fan-out shines when the pieces of work are independent — each piece doesn’t need to know what the others are doing.- One output per item — a tailored note per company, a check per device, a summary per ticket cluster.
- Multiple angles on the same question — investigate a topic from several sides at once and aggregate the findings.
- Bulk audits — sweep many systems for the same condition without waiting for each one in turn.
When It Doesn’t Fit
| Workload shape | Why fan-out hurts |
|---|---|
| Building something that has to fit together | A coherent app, a single long document, or a refactor across files — parallel pieces make conflicting choices and don’t compose. |
| Sequential work | If step 2 depends on step 1, there’s nothing to parallelise. A regular agent run is the right shape. |
| A handful of API calls | If the work is “make ten quick calls and combine the results,” a single agent with the right tools is cheaper than spinning up parallel runs. |
| Writes against shared records | Two parallel runs updating the same ticket or the same document can step on each other. Keep writes single-threaded. |
Safety
| Control | Behaviour |
|---|---|
| Capped parallelism | An agent can’t spin up more than 10 parallel pieces in one fan-out, and an agent run can fan out at most 5 times — so a single run is capped at 50 subagents total. If a job genuinely needs more, the agent splits it into batches; if it would exceed the 5-wave limit the run fails clearly rather than spawning indefinitely. |
| No runaway runs | Each parallel piece has a runtime ceiling. Anything that overshoots is stopped and reported back as a timeout rather than quietly burning resources. |
| No nesting | A piece that’s running in fan-out can’t fan out again. This keeps the worst-case cost and complexity bounded. |
Billing
Each subagent counts as its own agent execution. The cost of a fan-out run is the parent agent’s normal cost plus one execution per subagent — same rules you already know from Billing & Credits. How that breaks down depends on how the parent agent is set up:| Parent agent type | What each run costs |
|---|---|
| Triggered (runs on a ticket or time entry) | A flat cost per execution based on the agent’s most expensive tool — usually 1 credit, 2 if the agent uses Standard tools, 3 if it uses Advanced tools. Each subagent costs that same flat amount. |
| Scheduled (runs on a timer or manually from the dashboard) | Billed per tool the agent actually used — 1 / 2 / 3 credits per Basic / Standard / Advanced tool call. Each subagent is billed the same way, against the tools it called. |
Failed or timed-out subagents are still billed — they consumed work even if they didn’t return a useful result. The agent’s own self-assessment of execution quality (visible on the execution log) is separate from the credit charge.