<aside> 🦥

Sources

Choosing the Right Multi-Agent Architecture – LangChain

Effective context engineering for AI agents – Anthropic

Subagents in the SDK – Claude Code Docs

</aside>

🦥 Sloth's Simple Definition

<aside> 🦥

A subagent is a separate agent your main agent can spin up to handle one focused task. It has its own context window, own tools, and own instructions, does its job, then hands back only a short summary. Think of the main agent delegating to a specialist on the team.

</aside>

The #1 Reason: Context Isolation

<aside> 🦥

Every long agent session eventually fills its context window with noise and starts getting dumber. Subagents fix this:

• A subagent can burn tens of thousands of tokens exploring, reading files, and searching…
• …then return just a 1,000–2,000 token summary to the main agent.

All the messy intermediate work stays in the subagent and never pollutes the main conversation. This is called context compression.

</aside>

The Orchestrator Pattern

<aside> 🦥

Separate control from execution:

• Orchestrator: owns the goal, plan, and "what happens next." Doesn't do the work itself.
• Subagents: do the actual narrowly-scoped work.
• Verifier agents (optional): check whether output is good enough before moving on.

Mental model: less "super-agent," more "tech lead who refuses to write code."

</aside>

Subagent vs "Agent as a Tool"

<aside> 🦥

• Tool / agent-as-tool → simple, stateless, atomic job (reusable everywhere).
• Subagent → complex, multi-step sub-problem that needs its own context and autonomy.

Rule of thumb: stateless + simple = tool; owns a whole chunk of work = subagent.

</aside>

🦥 When To Reach For Them

<aside> 🦥

• Parallel work: spawn 5 subagents to explore 5 parts of a codebase at once.
• Long tasks: keep the main agent coherent over hours.
• Different perspectives: many reviewers + many judges = higher quality.

Start simple though: one agent first, build the workflow, THEN add subagents. Don't over-engineer. 🦥

</aside>