When NOT to Split

Over-spawning is a common mistake. Here's when to keep it simple.

Anti-Patterns

❌ Spawning for Simple Lookups

Bad:

"Spawn a sub-agent to check the weather"

Why it's bad:

• Weather check takes 2 seconds
• Sub-agent overhead takes longer than the task
• Main agent can do this trivially

Good:

Just check the weather directly with a tool

❌ Spawning When Context is Critical

Bad:

"Spawn a sub-agent to continue our conversation about the project"

Why it's bad:

• Sub-agent doesn't have conversation history
• You'll need to re-explain everything
• Context loss defeats the purpose

Good:

Continue the conversation in the main session

❌ Spawning for Everything

Bad:

"I'll have sub-agents for email, calendar, files, search..."

Why it's bad:

• Coordination overhead
• Context fragmentation
• Harder to maintain
• More expensive

Good:

Main agent handles most things, spawns only when truly needed

❌ Spawning Chains

Bad:

Sub-agent A spawns sub-agent B spawns sub-agent C...

Why it's bad:

• Exponential complexity
• Context loss at each level
• Hard to debug
• Expensive

Good:

Main coordinator spawns workers directly

The Simple Test

Before spawning, ask:

1. Will this take more than a few minutes?

   • No → Don't spawn

2. Can the main agent do this easily?

   • Yes → Don't spawn

3. Does the sub-agent need current context?

   • Yes → Don't spawn (or pass context explicitly)

4. Is the coordination overhead worth it?

   • No → Don't spawn

Real Examples