Do You Still Need Subagents, or Was That a Context Workaround?

What subagents were actually solving

Three distinct problems got bundled under one pattern.

Context pollution. An exploratory search that reads twenty files fills the window with material that is irrelevant once the answer is found. Delegating it to a subagent meant the main conversation received the conclusion instead of the search. This was the strongest original motivation and it was a workaround for a limit, not a design ideal.

Parallelism. Four independent investigations finish sooner run concurrently than sequentially. This is a wall clock argument and it is unaffected by how good the model gets.

Specialization. A reviewer agent with review instructions, a test writer with testing instructions. The theory was that a focused prompt produces better focused work.

Those three have aged very differently, which is why the pattern feels less necessary now without being obsolete.

Why two of the three faded

Context pollution stopped being the binding constraint once agents started managing their own windows properly: truncating large tool results, dropping superseded file contents, and summarizing exploration in place. The gain from moving that work into a separate process shrank, while the cost of the boundary stayed the same.

Specialization faded for a different reason. A specialist agent is mostly a prompt carrying domain knowledge, and prompts are an expensive place to keep knowledge. It is bought on every request and stale from the day it was written. Retrieval covers the same ground better: when the task is a review, the review standard is fetched; when it is a migration, the migration conventions are fetched. Same specialization, no separate agent to coordinate with, and the knowledge updates when the document does.

RDK is the layer that makes this substitution practical. Files from local vaults, docs, and code are indexed as encrypted private chunks, and the agent searches those chunks before querying a model. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved instead of regenerated, and a single agent behaves like whichever specialist the current task requires.

What still justifies a subagent

Genuine parallelism. Tasks that are independent, that do not need each other's intermediate results, and where waiting is the actual cost. Auditing six services for the same issue. Running the same migration check across many repositories. This case is unaffected by better context management, because the constraint is time, not window size.

Permission isolation. The strongest argument and the least discussed. An agent that reads untrusted input, web pages, tickets, user submitted content, should not simultaneously hold tools that spend money, send mail, or write to production. Separating those into different agents with different tool grants turns a prompt injection into a contained failure rather than an incident.

Blast radius on long autonomous runs. When something must run unattended for a long time, a bounded worker whose output is validated before it reaches the main context is easier to reason about than one long session.

Notice that all three are about isolation or wall clock time. None of them are about the model needing help thinking.

A decision rule

Ask what you are isolating.

If the answer is context, try managing context first: prune superseded output, retrieve instead of re-reading, and keep the task scoped. That is usually cheaper than a second agent and it keeps the reasoning in one place.

If the answer is time, and the tasks genuinely do not depend on each other, parallelize.

If the answer is privilege, split the agents, and split them along the boundary between reading untrusted input and taking consequential action.

If the answer is expertise, index the expertise instead of embodying it in a prompt. The specialist behaves better when its standard is a document that a human maintains and any agent can retrieve.