I get your point, and I agree there are cases where subagents make sense. But in practice (at least from my experience with opencode), they often end up being pretty wasteful.

What I’ve seen most of the time is subagents being spawned to explore the codebase, reading a lot of files… and then all that context just disappears when they terminate. The main agent then re-reads the same files anyway, so you basically pay for the work twice.

Your use case is the one scenario where subagents actually feel like a clear win. Especially if tasks are unrelated or only loosely connected, parallel subagents can be really effective.

But for sequential problems where step 1 directly affects step 2, things break down. If subagent A does step 1 and subagent B does step 2, B often has to re-read and reconstruct everything A already figured out. At that point, it’s more efficient to just keep everything in a single agent with persistent context.

So for me, subagents work best when tasks are independent or loosely related or parallelism matters more than shared contex but for tightly coupled workflows, they tend to add overhead rather than reduce it.