When One Agent Is Not Enough: Delegation, Durable Tasks, and Scheduling

DeerFlow’s coordination mechanisms answer a specific question: when should work leave the lead agent’s immediate loop, and what must be preserved when it does? This chapter compares direct execution, ordinary sub-agents, durable batches, scheduled runs, and long-running MCP tasks by independence, specialist benefit, context cost, side effects, latency, and recovery. The goal is not to maximize the number of agents, but to give each kind of work the smallest lifecycle that can own it safely.

Delegation is a decision about net benefit

DeerFlow explicitly makes direct execution the default. A lead agent should delegate only when the expected benefit is clear: independent scopes can reduce wall-clock time, a specialist has capabilities or instructions the lead lacks, or an unusually context-heavy investigation would otherwise displace important lead context. Complexity by itself is not enough. A large repository, a long prompt, or a task with many steps can still be cheaper and safer when the lead keeps the work in one feedback loop.

The costs are concrete. Starting a sub-agent adds setup and scheduling overhead. The child may repeat repository or source discovery that the lead has already done. The lead must inspect and synthesize another result. Shared files can create conflicts, and external actions can be duplicated or interleaved. If one delegated task needs the output of another, parallel execution turns a dependency into coordination work. DeerFlow’s routing guidance treats inter-agent dependencies and overlapping mutable state as hard vetoes for parallel dispatch.

This policy is easier to apply with a simple comparison. A request to inspect three independent sources and return a bounded finding from each may benefit from parallel specialist work. Each child can own one source, use a common output shape, and leave the lead to reconcile disagreements. A request to refactor authentication, update its tests, and respond to failures usually belongs with the lead. The edits, test feedback, and design decisions form one coupled stateful loop; splitting them creates more synchronization than speed.

Ordinary delegation starts with a bounded task description, not with a copy of the entire conversation. In the default isolated context mode, the child receives the delegated prompt and the information explicitly provided for that task. It has its own role, model, tools, skills, and termination conditions. This keeps an investigation focused and prevents unrelated lead context from consuming its input budget.

Sometimes the task depends on decisions or failed approaches already spread through the conversation. DeerFlow offers a snapshot context mode for that case. The child receives retained conversation and the parent’s compaction summary captured at dispatch, along with eligible text, tool descriptions and results, and serializable media. It does not inherit the parent’s system prompt, hidden framework messages, reasoning blocks, tool-execution metadata, pending calls, or the parent’s authority simply by seeing a snapshot. Snapshot context costs additional input tokens and is fixed at dispatch; it is background for the child’s own work, not a substitute for a bounded task description.

The distinction matters because context isolation and side-effect isolation are different. A delegated graph has its own internal messages and one-shot execution history, so its intermediate reasoning does not flood the parent conversation. But ordinary sub-agents still share the lead thread’s filesystem view. Two children that write the same report or mutate the same source tree can interfere even if neither can see the other’s hidden conversation.