Sub-agents or One Agent Context?
Keep one agent when the task depends on shared context or produces output the parent cannot verify. Delegate search and summarisation when exploration is large but the return is small, source-backed, and checkable. Limit parallel workers to the provider’s available rate budget.
The short answer
Keep one agent in one context when decisions depend on details accumulated during the run. Delegate when a task creates a large amount of intermediate material but has a small, checkable conclusion. Search and summarisation fit that shape: a child can inspect many documents, return a short finding with sources, and leave the parent’s context available for synthesis.
Do not delegate merely because a task can be split. A sub-agent introduces a lossy boundary, consumes a separate share of the model provider’s rate limit, and can return a confident error that the parent cannot detect. Parallel delegation magnifies each of those costs.
Anthropic’s December 2024 account of effective agent patterns recommends starting with the simplest workable system. It identifies parallel calls as useful for independent subtasks and an orchestrator-worker pattern as suitable for search across multiple sources. That supports a narrow rule: delegate independent exploration, not work whose correctness depends on an unbroken chain of context.
How the three choices compare
| Criterion | One agent, one context | Sequential sub-agents | Parallel sub-agents |
|---|---|---|---|
| Context | Retains the full working history, but intermediate output competes for context space | Gives each delegated task a fresh context window | Gives every delegated task a fresh context window at the same time |
| Boundary | No parent-child handoff | One lossy handoff per child | Several lossy handoffs that the parent must reconcile |
| Provider rate | One active stream of model calls | Adds calls without multiplying concurrent demand by worker count | Multiplies concurrent rate consumption by the number of active children |
| Error checking | The agent can inspect its own preceding evidence | The parent must verify the returned conclusion | The parent must verify every return and resolve conflicts |
| Best fit | Context-dependent reasoning and final integration | Large exploration with a small, checkable result | Independent, source-checkable searches when rate capacity exists |
What a fresh context window buys
A long-running agent has a finite context window. Tool results, search pages, logs, discarded approaches, and intermediate drafts all occupy space that could otherwise hold the task, constraints, and decisive evidence. The March 2025 revision of the survey of LLM-based autonomous agents describes the context window as an agent’s short-term memory and identifies its limited size as a restriction on comprehensive memory.
A sub-agent moves one branch of work into a clean window. Its value is not a different personality or a job title such as “researcher.” Its value is that the branch can consume a large context without filling the parent’s window. Work whose intermediate output is large and whose conclusion is small is therefore exactly what should be delegated.
Suppose the parent needs to know whether several primary sources support a particular condition. The child may run many searches and reject most results. The useful return could be three source URLs, the relevant passages, and a two-sentence conclusion. Keeping that entire search trail in the parent would spend context on material that does not affect the final decision.
This is also why delegation is the wrong answer when the intermediate reasoning is itself the product. If the parent must understand each decision to edit code safely, reconcile interacting requirements, or defend a conclusion, compressing the path into a child’s summary removes information the parent still needs. Use context-window management inside one agent before splitting work whose parts are tightly coupled.
The handoff is lossy
A child does not inherit the parent’s knowledge unless the parent passes it. The child cannot ask about a constraint that it does not know exists, and the parent sees only what the child returns. That boundary loses both directions of context: omitted instructions on the way down and omitted evidence on the way back.
The practical cost is specification work. A useful delegation must state the question, scope, allowed sources, expected return format, and what uncertainty to report. If writing that packet requires reproducing most of the parent’s context, delegation has lost its main advantage. Keep the work in one context.
A good child return is deliberately narrow: conclusion, evidence, source locations, and unresolved gaps. A bad return is a polished essay that hides which statements came from which source. The parent should be able to repeat the decisive check without replaying the child’s whole search. This is the same boundary discipline needed when validating agent tool results before they enter the next model call.
Parallelism is capped by the provider
Parallel children may reduce elapsed time when their tasks are independent, but they do not make model capacity free. If one worker consumes requests or tokens at rate r, then n workers with comparable call patterns demand roughly n × r while they run. Parallel sub-agents therefore multiply rate consumption by their count. The provider limit, rather than the machine running the orchestrator, caps useful fan-out.
This distinction matters because a local process can start many workers long before the model provider will serve all their requests. Once calls are throttled, extra workers wait, fail, or retry instead of completing useful work. The result can be more consumption without a corresponding reduction in elapsed time.
The AWS Builders’ Library guidance on timeouts, retries, backoff, and jitter explains the relevant distributed-systems mechanism: retries add load, and repeated retries can worsen an overloaded dependency. For sub-agents, cap concurrency before dispatch, set a stopping condition, and back off throttled calls. Backoff can spread retries; it cannot increase the provider quota.
Sequential delegation avoids the fan-out spike but still pays for every child call and every lossy handoff. Choose it when fresh contexts matter but completion time does not justify concurrent demand. Choose parallel delegation only when the branches are independent and the available rate budget can support their combined peak.
The extra failure mode
A single agent can be wrong, but delegation adds a failure mode the single-context design does not have: a child can return confidently wrong output that the parent has no way to check. The parent may mistake concise prose for completed investigation because the discarded search trail is outside its context.
Adding more children does not automatically fix this. Agreement can mean that several children made the same unsupported inference, while disagreement leaves the parent with another synthesis problem. The safe condition is not “multiple opinions.” It is independently checkable evidence.
That is why search and summarisation are the most reliable delegation pattern. Require source locations with every material finding, give the parent access to the same sources, and make the parent check the claims that control the decision. If the child’s sources are unavailable to the parent, its conclusion should remain unverified rather than becoming an input to action.
Which to pick when
Pick one agent in one context when the task depends on shared history, interacting constraints, or reasoning that the final decision-maker must inspect. It is also the right default when the result cannot be checked against tests, source documents, or another reachable record.
Pick sequential sub-agents when exploration would crowd out the parent’s useful context, each branch can return a small result, and provider rate capacity is tight. Define the handoff while doing agent task decomposition: include the exact question, evidence requirements, and stopping condition.
Pick parallel sub-agents when the searches are genuinely independent, their returns are verifiable against sources the parent can also reach, and the provider’s rate budget can carry the combined demand. Cap the worker count at that budget. If any of those conditions is missing, keep one agent or delegate the branches sequentially.
Sources
See also
A step-by-step guide to building a CI suite for AI systems: property assertions, pass-rate thresholds, and setting a tolerance your team will not ignore.
How head and tail sampling behave at agent-scale trace volume, what tail buffering costs, and how to keep decisions consistent across services.
Cloudinary's unauthenticated agent account-creation endpoint: what it returns, why email verification gates it, and when to use it.
Build a result boundary that rejects malformed, oversized, or ambiguous tool output before a model can read it.