Answering one architectural question means reading roughly forty files, and you need the session you are working in to stay usable for the rest of the day. You ask Claude to delegate the reading to a subagent. What does that achieve?

The principle — the scarce resource in a long session is the context window you are steering, and it is spent by reading far faster than by reasoning. Delegation exists to spend somebody else's.

Why the key is correct — Anthropic names the trigger for delegation as a task that produces verbose output you do not need in your main context, and describes the mechanism as a subagent that reads files in its own context window and reports a summary. The best-practices guidance says the same thing as advice: scope investigations narrowly or use subagents so the exploration does not consume your main context. Forty file reads for one decision is exactly that shape, and the session staying usable afterwards is what you are buying.

Why the others are wrong — concurrency is a consequence of being able to delegate, not the documented purpose, and running several workers at once multiplies token usage rather than saving anything. The worker's reading is never added to your session; a summary is what returns, and if the reads came with it nothing would have been achieved. And a summary written inside your own session does not undo the reads that produced it — they stay in the window for the rest of the day.

Remember this — the purpose is context economy. Speed is a side effect, and it is one you pay for in tokens.

Sources — Anthropic's Claude Code subagents, common-workflows and best-practices documentation.