Fan-Out Economics: Cost When Agents Spawn Agents

When an agent can spin up other agents, your cost stops being a line and becomes a tree. A single user request that looks like one task on the invoice can quietly explode into dozens of model calls, each with its own context, retries, and tool charges. Fan-out economics is the discipline of pricing that tree before it bankrupts your margin. This piece gives you a concrete cost model, the variables that actually move the needle, and the failure modes that catch most GaaS vendors off guard.

Why Fan-Out Breaks Naive Cost Math
The Fan-Out Cost Tree, Defined
A Working Cost Model You Can Actually Use
The Core Equation
Worked Example: A Research Agent
The Variables That Actually Move Cost
Branching Factor and Depth
Context Re-Hydration
Orchestration Overhead
Where Fan-Out Cost Hides on Your P&L
How to Price a Product That Spawns Itself
Insights Most People Overlook
References

Why Fan-Out Breaks Naive Cost Math

Most early cost models for agentic AI assume something like a straight line: a user submits a task, the agent makes some calls, you tally the tokens, you slap a margin on top. That works fine for a single-shot summarizer. It falls apart the moment your agent can delegate.

The problem is structural, not incremental. A planner agent that decomposes a goal into seven subtasks and hands each to a worker isn't doing seven times the work of a one-shot call. It's doing the planning, plus seven workers, plus each worker's own tool calls and retries, plus a synthesis step that re-reads everything the workers produced. The cost compounds at every level. Anthropic's own engineering team has written about how its multi-agent research system burns roughly fifteen times the tokens of a plain chat interaction, and that's a number from a team that knows exactly what it's doing.

Fifteen times is the headline figure people remember. The number that should scare a CFO is the variance. A simple query might fan out to three calls; a hard one to fifty. When your unit of sale is "one task" and your unit of cost swings by an order of magnitude depending on inputs you can't see in advance, you don't have a pricing model. You have a bet. This is the same tension explored in #21: Why per-task pricing makes forecasting nearly impossible, but fan-out makes it sharper, because the agent itself is the thing deciding how big the bill gets.

The Fan-Out Cost Tree, Defined

Picture the actual call graph of a delegating agent. At the root sits the orchestrator. It produces a plan and spawns child agents. Each child may spawn its own children, call tools, and loop until it's satisfied. When children return, the orchestrator synthesizes. That graph has three properties that determine cost:

Branching factor (b): how many sub-agents each parent spawns on average.
Depth (d): how many levels deep the delegation goes before leaves do the actual work.
Per-node cost (c): the token and tool spend at each node, which is rarely uniform.

If branching and per-node cost were constant, total node count would grow like b^d, and cost would grow with it. In practice the tree is lopsided and the leaf nodes (the workers actually reading documents or running tools) are far more expensive than the interior planning nodes. But the mental model holds: cost is the sum over every node in the tree, and the tree's shape is decided at runtime by the model, not by you at design time.

This is why fan-out economics is its own topic and not just a footnote to token accounting. The expensive part isn't any single call. It's that the structure multiplies. Two related cluster pieces matter here: #3: The hidden cost of retries covers what happens when one branch loops, and #47: How tool-call costs stack and compound in agent workflows covers the tool spend riding on each node.

A Working Cost Model You Can Actually Use

Skip the b^d idealization. Real trees are too irregular for it. Here's a model that survives contact with production.

The Core Equation

Treat the system as a set of node types, each with an expected count and an expected cost. For a typical orchestrator-worker pattern:

Total cost per task =
 C_orchestrator (plan + synthesize)
 + N_workers × (C_worker_base × R_worker) (worker calls × retry multiplier)
 + N_tool_calls × C_tool (search, code exec, API)
 + N_workers × C_context_rehydration (re-passing context per worker)

Where:

C_orchestrator = input + output tokens for planning, plus the synthesis pass that re-reads worker outputs (often the single largest line, because synthesis ingests everything).
N_workers = expected number of spawned workers (your branching factor times depth, empirically measured, not assumed).
R_worker = a retry/loop multiplier, usually 1.3 to 3.0, capturing the fact that workers iterate.
C_context_rehydration = the cost of re-sending shared context (the goal, prior findings, tool schemas) into every child. This is the line everyone forgets.

The discipline here is to measure each term from logs rather than guess it. Most teams overestimate worker count and badly underestimate rehydration and synthesis.

Worked Example: A Research Agent

Say you sell a per-task research agent. A medium-complexity query produces:

Orchestrator: 8K input + 2K output for planning. Then a synthesis pass that ingests 40K tokens of worker output and emits 3K. Call it roughly $0.20 at frontier-model rates.
Five workers, each averaging 15K input (context + their slice) and 4K output, with a retry multiplier of 1.6. That's five workers doing the equivalent of eight full passes. Roughly $0.55.
Twenty tool calls (web search + fetch) across the workers at a few cents each. Roughly $0.40.
Context rehydration: each worker gets ~10K tokens of shared context re-sent. Five workers, plus retries, means you're paying to transmit the same goal and findings six or seven times. Roughly $0.18.

That single task lands near $1.33 in raw COGS. Price it at "one research task for $2" and your gross margin is around 33 percent before you've paid for anything else. Now imagine the hard query that fans out to twelve workers at depth three. The same $2 price tag is underwater. This is the exact margin trap dissected in #22: The margin trap of "we'll just pass through model costs": the average looks fine, the tail kills you.

The Variables That Actually Move Cost

If you only instrument three things, instrument these.

Branching Factor and Depth

Branching factor is the highest-leverage knob you control. Going from an average of three sub-agents to five isn't a 67 percent cost increase; once you account for the synthesis pass that has to read all of their output, it's often closer to doubling. Depth is worse, because every additional level adds a planning node and re-rehydrates context for a whole new generation of children.

The practical move many vendors make is to cap branching and depth hard, then let the agent request more budget only when a confidence signal justifies it. That's not just a reliability choice; it's a margin choice. The trend is real enough that it gets its own cluster entry, #27: Why some agent startups are quietly capping autonomy to protect margin.

Context Re-Hydration

Here's the dirty secret of fan-out: a huge share of your token bill is the same context paid for over and over. The orchestrator's goal, the accumulated findings, the tool schemas, the formatting instructions, all of it gets re-sent into every child, and again on every retry. In a wide, shallow tree, rehydration can rival the cost of the actual reasoning.

This is where prompt caching earns its keep. Providers like OpenAI document automatic prompt caching and Anthropic offers explicit cache control; both can cut the cost of repeated context dramatically when shared prefixes stay stable across child calls. Architecting your sub-agent prompts so the shared prefix is identical and cacheable is one of the few free lunches in this whole business. The broader lever is covered in #26: Caching, memory, and the quiet levers of agent gross margin.

Orchestration Overhead

The planner and the synthesizer are not free, and the synthesizer scales with how much the workers produced. A team that optimizes worker calls but lets workers return verbose, unstructured output will get clobbered at synthesis time, because that final pass ingests everything. Forcing workers to return compact, structured results is a direct cost reduction at the most expensive node in the tree.

Where Fan-Out Cost Hides on Your P&L

Fan-out cost is sneaky precisely because it doesn't show up where you look. A few places it hides:

In the average. Your dashboard shows a healthy mean cost per task. It's hiding a long right tail of pathological fan-outs that eat your worst customers' margin entirely. Always watch p95 and p99 cost per task, not just the mean.
In idle and abandoned branches. A worker that gets spawned, does half its work, and gets discarded when the orchestrator changes plans still cost money. See #12: The "idle agent" cost problem and how vendors hide it.
In retries you didn't log as retries. When a sub-agent silently loops three times before succeeding, naive logging records "one worker," and your model undercounts.
In shared infrastructure. When ten customers' tasks all hit the same orchestration layer, attributing the spawned-tree cost back to the right customer is genuinely hard. That's the whole subject of #11: Cost attribution: charging the right customer for shared agent infrastructure.

The fix is per-task cost telemetry that traces the entire tree, tagged to a request ID, with every node's tokens, tool calls, and retries attributed to the leaf that incurred them. If you can't reconstruct the cost tree for any given invoice line, you can't price the product.

How to Price a Product That Spawns Itself

Three viable postures, each with a different risk profile.

Pass-through with a markup. You charge a multiple of measured spend. Honest, but it transfers all the fan-out variance to the customer, who hates a bill that swings 10x for reasons they can't see. Finance teams revolt; see #43: Why finance teams hate consumption pricing.

Fixed per-task with a hard budget cap. You price the average task and enforce a token/spend ceiling per invocation. The agent degrades gracefully (fewer workers, shallower tree) when it approaches the cap rather than blowing your margin. This is the most defensible model, and it forces you to actually design the fan-out budget. McKinsey's work on the economics of scaling generative AI repeatedly lands on the same point: the cost discipline has to be designed in, not bolted on.

Per-outcome. You charge for the result, eat all the fan-out risk yourself, and live or die on whether your average tree cost sits comfortably below your price. Only do this once you've measured your p99, not your mean.

Whichever you pick, the non-negotiable is a runtime budget. An agent allowed to spawn without a ceiling is a runaway-spend incident waiting to happen, the scenario modeled in #48: Modeling worst-case spend: the runaway-agent budget scenario. The budget isn't a constraint on capability. It's the thing that makes the capability sellable.

Insights Most People Overlook

1. Synthesis, not delegation, is usually your most expensive node. Everyone obsesses over how many workers spawn. But the orchestrator's final synthesis pass ingests the combined output of every worker, which means it's often the single largest token line in the entire tree. Optimize worker output compactness before you optimize worker count.

2. Caching changes the optimal tree shape. Without prompt caching, deep narrow trees can be cheaper because they rehydrate less context. With aggressive caching of a stable shared prefix, wide shallow trees become cheaper because the repeated context is nearly free. Your cost-optimal architecture is downstream of your caching strategy, not independent of it.

3. The variance is the product risk, not the mean. A team can hit a great average cost per task and still go bust, because per-outcome pricing exposes you to the tail. A handful of customers whose queries reliably trigger 12-worker fan-outs can turn a 40 percent blended margin into a 40 percent loss on that cohort. Cohort-level cost analysis (see #30) matters more here than in almost any other software category.

4. Falling token prices won't save you, because fan-out scales the call count. When inference gets cheaper, teams respond by letting agents fan out wider and deeper, because they now can. The cost per token drops; the tokens per task climb to match. This is the fan-out version of the broader observation in #9: Why falling token prices didn't lower agent bills: the structure absorbs the savings.

5. Capping autonomy is a feature you can sell, not just a cost control. A predictable, budgeted agent that occasionally says "this is as far as I'll go without more budget" is easier for an enterprise buyer to trust than an unbounded one. The cap that protects your margin also protects the customer's, which is a rare alignment worth marketing.

Fan-Out Economics: How to Model Cost When Agents Spawn Sub-Agents

Table of Contents