Module 5: Subagents
A subagent does one thing well. That's its entire job description.
Why Subagents Matter​
The temptation is to build one powerful agent that handles everything. In practice, that agent ends up with a 200-line system prompt, 15 tools, and reasoning that takes 30 seconds per request because it's evaluating options it doesn't need.
Subagents solve this by splitting responsibilities. Each subagent has a narrow focus, a small prompt, and only the tools it needs.
In Our Contract Workflow​
| Subagent | Responsibility | Tools | Prompt Size |
|---|---|---|---|
| Extraction Agent | Parse PDF, identify clause boundaries, extract structured data | extract_pdf | ~10 lines |
| Vendor Lookup Agent | Pull vendor history, past contracts, dispute records | lookup_vendor, search_history | ~8 lines |
| Compliance Agent | Compare clauses against policy templates, flag deviations | check_policy, get_regulations | ~15 lines |
| Financial Agent | Calculate exposure, model penalty scenarios | calculate_exposure | ~12 lines |
| Report Agent | Generate formatted executive summary | generate_report | ~10 lines |
Compare that to a single agent with all 8 tools and a 50+ line prompt. The subagent approach is faster, cheaper, and easier to debug.
Design Principles​
Single responsibility. If you can't describe what the subagent does in one sentence, it's doing too much. "Extracts structured clause data from PDFs" is one responsibility. "Extracts clauses and checks compliance" is two.
Defined interface. Every subagent has a clear input schema and output schema. The orchestrator doesn't need to know how the subagent works internally. It just needs to know what to send and what to expect back.
Independent testing. You should be able to test any subagent in isolation by giving it sample input and checking the output. If testing a subagent requires running the entire system, your boundaries are wrong.
Minimal tools. Each subagent gets only the tools it needs. The extraction agent has no access to the CRM. The vendor lookup agent has no access to the policy database. This limits blast radius when something goes wrong.
When to Split an Agent​
You should split an agent into subagents when:
- Its prompt keeps growing because it handles too many scenarios
- It has tools that are only used for certain input types
- Debugging requires tracing through multiple unrelated reasoning paths
- Different parts of its work could run in parallel
Shared vs Isolated Context​
Subagents don't share memory by default. The extraction agent's findings don't automatically appear in the compliance agent's context. The orchestrator is responsible for passing relevant data between them.
This is a feature, not a bug. Isolated context means one subagent's mistakes don't contaminate another's reasoning. The orchestrator decides what each subagent needs to see.
What's Next​
Subagents need knowledge beyond their training data to do their job well. In Module 6: RAG, we cover how to give agents access to your organization's specific knowledge at query time.
Subagent Design Lab
Design and build 5 specialized subagents with defined interfaces, independent test suites, and integration with an orchestrator.