One request, thirteen agents.
August 16, 2026
Nearly every conversation about AI cost starts at the price per million tokens. That number is usually not the problem. The problem is that one user request no longer means one model call — it means a tree of them, and the tree has no natural size. DeepSeek Harness treats that tree as a first-class subsystem with an explicit cap, which makes it a useful place to see the mechanism clearly.
The arithmetic nobody puts in the business case
A parent agent that delegates to three children, each of which delegates to three more, has turned a single user request into thirteen agents. Nobody chose thirteen. It fell out of two independent decisions that each looked reasonable in isolation.
This is the orchestration multiplier, and it sits on top of the multiplier you already know about — the several model calls a single agent makes to complete one task. The two compound.
Two delegation shapes, two cost profiles
| Shape | Behaviour | Cost character |
|---|---|---|
| One-shot | Create, prompt, await, dispose | Bounded and attributable to one parent turn |
| Continuable | Durable background session, resumed later | Open-ended, accrues across turns |
The second one carries a charge most teams have never priced. When a continuable child is woken after being idle, it is reconstructed from its stored session record — which costs input tokens proportional to how long that record has grown. A long-lived background agent gets more expensive to wake the more it has done.
The cap that cannot be laundered
Delegation depth here is persisted with the session and tracked at runtime as the greater of the stored and current values. Two rules protect it: resuming a stored session cannot lower the depth, and a delegation is rejected if the resulting depth would exceed the configured maximum. You cannot reset the counter by restarting a child.
That second rule is the one worth carrying into any governance conversation. A limit that a restart can quietly clear is not a limit.
Requests fail loudly when a capability is missing
Before delegating, the harness checks the requested capabilities — an output schema, a depth limit, a tool filter, a persona — against the chosen provider. The documentation is explicit that a request needing something the provider cannot do is rejected with a typed error rather than accepted and then ignored.
That is the right default for a control. Silent degradation is how a tool filter meant to keep an expensive capability out of a cheap child stops applying, and nobody finds out until the invoice arrives.
Failed delegations are pure waste
Every delegated run returns a stop reason from a fixed set: completed, aborted, error, out of tokens, refused. Anything other than completed means partial output. That distribution is the cheapest cost report in the system, because a run that ended for any of the other four reasons consumed tokens and produced nothing usable.
A rising share of out-of-tokens outcomes in particular usually means the delegated task was scoped wrong, not that the budget was too small.
Four questions for the platform team
- Descendants per user request. Not children — the full tree.
- Deepest observed delegation against the configured maximum. If there is no maximum, that is the finding.
- Cost of waking a background agent, and how that cost has trended as those agents accumulate history.
- Share of delegated runs not ending in completion. This is the waste line.
The caveat
DeepSeek Harness is a developer preview and its own documentation warns of compatibility-breaking changes. The specific names will move. The structure — bounded depth, fail-loud capability checks, an explicit stop reason on every delegated run — is the requirement to hold your own system to.
Related
- Your agent harness decides how much lock-in you buy
- When should an agent stop? DeepSeek Harness goals
- Budget enforcement belongs inside the agent loop
- An agent audit trail finance can actually read
FAQ
What are subagents in DeepSeek Harness?
Subagents are a capability seam, registered by name so multiple providers can coexist. Delegation runs either as a one-shot child that is created, prompted, awaited and disposed, or as a continuable background child that persists across turns.
Why does delegation multiply AI cost?
Because each level of delegation multiplies the model calls made per user request. A parent that spawns three children, each spawning three more, has turned one request into thirteen agents. Without a depth cap the fan-out has no defined upper bound.
How is delegation depth controlled?
Depth is persisted in the session header and tracked at runtime as the greater of the stored and current values. A cold resume cannot lower it, and a delegation start is rejected outright if the derived depth would exceed the configured maximum.
What should finance ask about agent delegation?
Three numbers: descendants per user request, maximum observed delegation depth against the configured cap, and the share of delegated runs that ended for a reason other than completion. The third is spend that produced nothing.