Answer
When should you use a subagent?
When a piece of work would fill the main context with material the rest of the job does not need.
When a task will read far more than its answer needs to contain. The subagent absorbs the reading and returns the conclusion, keeping the main run's context matched to the work it still has to do.
The clearest criterion is a ratio. A task that reads forty files to establish one fact has a high ratio and is an excellent candidate: the forty files stay out of the main run and the fact comes back. A task that reads one document and returns a paragraph has a low ratio and gains nothing from delegation, because the material and the answer are the same size and the handover costs more than it saves.
That framing explains the tasks people find work best. Searching for where something is defined. Establishing whether a pattern exists across a codebase. Checking a claim against a set of sources. Summarising a long document down to the part that bears on a decision. Each involves a lot of intake and a small output, and each leaves the main run holding a conclusion rather than a pile of evidence.
The second criterion is independence. A subagent works from what it was given and cannot ask, so a task that requires ongoing clarification is a poor fit — the delegation turns into a guess. Tasks that can be stated completely in advance, with a defined output, are the ones that survive being handed over. If you cannot write the brief without expecting a follow-up conversation, the work belongs in the main run.
The third is that the result must be verifiable without repeating the work. A subagent returns a claim, and if checking it means reading everything it read, the delegation achieved nothing. Requiring the answer to carry its evidence — the file and line, the quotation, the specific record — is what makes the compression legitimate rather than merely convenient.
There is a real cost that should be counted rather than assumed away. The subagent has less context than the main run, so it may misinterpret the task in ways someone with the full picture would not. It returns a summary written by a party that saw more than you do, so the losses are unannounced. And the round trip costs time and tokens. Where the ratio is high these are worth paying; where it is not, they are the whole transaction.
The commonest mistake is delegating for tidiness rather than for context. Splitting a job into subagents because the structure feels cleaner adds handovers, latency and interpretation loss without addressing any actual constraint. The question is always what would fill the main context that this keeps out, and if the answer is not much, the work belongs where it already was.
Delegate the reading, not the thinking, and judge a subagent by how much it read against how little it had to say.
Siddharth Sharma, Context Theory
Related questions
Should a subagent do work that changes things?
Prefer not to, and where it must, keep the action narrow and reported. A delegated run has less context and its output is reviewed as a summary, which means an unexpected change is doubly hidden. Delegating the investigation and keeping the action in the main run preserves both the context saving and the visibility.
How do you know a subagent did the work properly?
By what it returns rather than by asking. An answer with file references, quotations or record identifiers can be spot-checked in seconds; an answer that is a confident summary cannot be checked at all without redoing it. Specifying the evidence format in the brief is what makes the difference, and it costs a line.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | The criterion for delegation is the ratio between material read and result returned, so a task consuming a large body of evidence to produce a small conclusion gains from a subagent while one whose input and output are similar in size does not. | Estimating the volume a candidate task must read against the size of the answer it must return. |
| Software | A subagent cannot ask for clarification, so a task requiring ongoing interpretation becomes a guess when delegated, which makes completeness of the brief a precondition rather than a refinement. | Attempting to write the delegated brief and observing whether it can be completed without anticipating a follow-up exchange. |
| Response | A delegated result is only useful if it can be verified without repeating the work, which requires the answer to carry file references, quotations or record identifiers rather than being a confident summary. | Attempting to check a returned conclusion using only what the subagent supplied alongside it. |
| Buying behaviour | Delegation costs interpretation loss from reduced context, unannounced omissions in the returned summary, and a round trip in time and tokens, all of which are the entire transaction where the read-to-result ratio is low. | Comparing the total cost and accuracy of a low-ratio task performed inline and delegated. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one