When to Split Work Into Sub-Agents (And When Not To)
After building my first few sub-agents, I got a little carried away. Every task became a candidate for its own agent. Code review? Agent. Documentation? Agent. Writing commit messages? You guessed it.
Turns out, more agents isn’t always better. I wasted a lot of time debugging coordination issues that wouldn’t have existed if I’d just kept things simple.
The Thing That Actually Matters
I used to think sub-agents were about “separation of concerns.” Sounds smart, right? But the real reason they’re useful is simpler: context isolation.
When you spawn a sub-agent, it starts fresh. It doesn’t know about the 50 messages you exchanged debugging that weird race condition. It only sees what you give it. That constraint forces you to think about what context actually matters for a task.
Mistakes I Made
Splitting too early. I’d design five agents before writing any code. Then I’d spend more time wiring them together than actually solving the problem. Now I start with one agent and only split when I feel the pain.
Running everything in parallel. Felt efficient. Wasn’t. If agents need each other’s outputs, you’ve just built a distributed system. I didn’t want to build a distributed system.
Agents that were too narrow. I had an agent whose only job was formatting error messages. That’s not an agent, that’s a function. The overhead wasn’t worth it.
What Works for Me
The sub-agents I actually keep using have a few things in common:
-
They know when they’re done. Clear success criteria. Not “review this code” but “find security issues and return them with line numbers.”
-
Small input surface. A file path. A diff. A specific question. Not “here’s everything, figure it out.”
-
Output I can use directly. If I have to interpret or transform what the agent returns, the boundary is probably wrong.
The Test I Use Now
Before creating a sub-agent, I ask: if this thing fails or returns garbage, can I detect it and recover without messing up my main workflow?
If yes, it’s probably a good boundary. If failure cascades into unclear state, I need to rethink it.
Honestly, Just Start Simple
My real advice: don’t start with sub-agents. Use one agent for everything. Feel where the context gets polluted. Notice what you keep repeating. Find the actual pain points.
Then extract sub-agents one at a time. You’ll build something better than if you’d designed it all upfront.