A fire-dispatch after-action review needs a single search across one directory of incident logs - a job that takes a few seconds and returns a handful of matches. An engineer proposes delegating it to a subagent to keep the main context clean. What is the right call?
Select an answer to reveal the explanation.
Short Explanation
Delegation has a cover charge—a fresh context, its own instructions, a summary trip home. For a one-shot search over the incident logs, the overhead costs more than the search.
Full Explanation
Delegation buys two things: context isolation and parallelism. Both benefits scale with the size of the work being isolated, while the cost of spawning a subagent is roughly fixed. That ratio, not tidiness in the abstract, is what decides whether a fire-dispatch log search belongs in a subagent.
A single search over one directory returning a handful of matches produces almost nothing to isolate, so the parent's context is never at risk. Paying for a fresh context window, a separate instruction set, and a return summary in order to protect against a few lines of output is pure loss. The useful heuristic is to delegate when a task will generate substantially more intermediate material than its conclusion.
Treating a launch as effectively free ignores the per-spawn context and the summarization round trip, which are paid regardless of how established the parent session is. Routing every tool call through a subagent multiplies that overhead across the whole run and adds latency to operations that return almost no output. The claim that subagents cannot run search tools is simply false—search is among the most common delegated tasks—so it reaches a defensible conclusion by an incorrect route.
Exam caveat: the threshold is about output volume, not wall-clock time—a fast tool that dumps an enormous payload is still worth isolating. Operational check: estimate the intermediate output a task will produce; if it is comparable in size to the summary it would return, run it inline.