Subagents get introduced as an intelligence pattern. Decompose the problem, give each part to a focused agent, combine the results. That framing is fine and it is not the reason most teams should adopt them.
The immediate, measurable benefit is narrower: a subagent that reads something large pays the cost once and then disappears. The main thread never carries the material, so the next fifty turns never pay to resend it.
One analyst reads the policy
The comparison that makes this land in a business conversation.
A two-hundred-page policy document needs to be understood. One analyst reads it and comes back with ten lines: here are the three clauses that affect us, here is the deadline, here is the one ambiguity that needs legal input. The rest of the team never reads the policy, and every subsequent discussion proceeds on the ten lines.
The alternative, where everyone reads the whole thing and carries it into every meeting, is obviously absurd when described in human terms. It is exactly what happens by default when a large file is read into a main agent thread.
The cost shape
This is worth being precise about, because it explains why the effect is larger than it looks.
Reading a large file into the main thread costs you once for the read. It then costs you again on every subsequent turn, because the content is now part of the context that gets resent. A file read at turn 20 of a 300-turn session is paid for 281 times.
Reading it in a subagent costs the read, plus the cost of the findings coming back, and nothing after that. The subagent's context is discarded when it finishes.
Nothing about the work changes. The same material is read with the same care. What changes is whether it stays resident in a context with a long life ahead of it.
Where to draw the boundary
Not everything belongs in a subagent, and over-applying the pattern produces its own problems: too many round trips, findings that lack the context to be useful, and a main thread that has to re-derive things the subagent already knew.
The useful test is volume in, volume out. A task that consumes a lot of material and produces a small, well-specified result is a good subagent. A task that needs continuous back-and-forth with the main thread's reasoning is not.
Four that work well in practice:
Document exploration. A tender explorer reads the bid pack and returns structured requirements. High volume in, a schema out.
Repository investigation. A repo explorer inspects code and returns specific findings: where this is implemented, what calls it, what would break. This is the highest-value one for coding agents, because repository reads are the most common source of large context steps.
Evidence gathering. An architecture evidence subagent reads reference documents and returns source-backed assumptions, each with a citation. The citation is what makes the findings usable without the source.
Log and usage analysis. A cost-analysis subagent reads usage logs and returns the top drivers. Logs are enormous and almost entirely uninteresting, which is the ideal profile.
What the subagent must return
The pattern fails when the findings are not self-sufficient, and this is the design detail that decides whether it works.
If a subagent returns "the deadline is 14 March", the main thread has a fact it cannot verify and cannot reason about. If it returns "the deadline is 14 March, from clause 4.2 on page 6, stated once and not contradicted elsewhere", the main thread has something it can act on, cite and escalate.
Specify the return shape before building. A subagent with a vague brief returns prose, and prose has a way of growing until it is the document again.
The governance dimension
There is a second benefit that has nothing to do with cost and is worth having anyway.
A subagent with a defined input and a defined output is a reviewable unit. Somebody can ask what the explorer was given and what it returned, and get a clear answer. A main thread that read forty files over three hours is much harder to reason about after the fact.
That matters for the same reason session hygiene matters: the record has to be legible to be useful. It also makes the components individually testable, which is what allows them into an eval suite rather than only being assessed end to end.
What good looks like
Large reads happen in subagents by default, not by exception.
Every subagent has a specified return shape, decided before it is built.
Findings come back with sources, so they are usable without the material.
The main thread's context stays roughly flat across a session, which is now something you can see because you instrumented it.
Practical checklist
- Route repository and document exploration into subagents as the default
- Apply the volume-in, small-result-out test before creating one
- Specify the return schema before building the subagent
- Require sources in the findings, not just conclusions
- Watch main-thread context delta to confirm the isolation is working
- Do not decompose tasks that need continuous back-and-forth
How CloudNala can help
We treat subagent boundaries as an architecture decision with a cost consequence, which tends to produce different answers from treating them purely as a reasoning pattern. The practical work is identifying which reads dominate context growth, defining the return shapes so findings are usable without the source material, and confirming afterwards from the telemetry that main-thread context actually stopped growing.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za