Suitable scenarios
Agent Teams is powerful, but not every task is suitable for it. Understanding the right scenarios helps you choose correctly.
Loading lesson…
Loading lesson…
Agent Teams is powerful, but not every task is suitable for it. Understanding the right scenarios helps you choose correctly.
Complex system refactors
When the refactor spans multiple modules with clear boundaries:
Scenario: split a monolithic application into microservices
Create a team:
- Teammate A: analyze dependencies in the user module
- Teammate B: analyze dependencies in the order module
- Teammate C: analyze dependencies in the payment module
- Teammate D: design the inter-service communication protocol
These modules can be analyzed simultaneously, and the final result can be synthesized later, which is much faster than analyzing them serially.
Multi-angle code review
When you need to review code from several dimensions:
Scenario: conduct a full security review of the payment module
Create a team:
- Teammate A: focus on security vulnerabilities (SQL injection, XSS, etc.)
- Teammate B: inspect performance issues (N+1 queries, memory leaks, etc.)
- Teammate C: verify completeness of error handling
- Teammate D: evaluate test coverage
Each member focuses on one dimension, making the review deeper, and the final report more complete.
Parallel frontend and backend development
When you need to build frontend and backend at the same time:
Scenario: build a user management feature
Create a team:
- Teammate A (frontend): implement the user list page
- Teammate B (frontend): implement the user edit page
- Teammate C (backend): implement the CRUD API
- Teammate D (coordination): design the API contract and make sure frontend and backend stay aligned
Frontend and backend can move in parallel as long as the API contract is defined first, following the contract-first principle.
Competitive debugging
When you have multiple possible solutions:
Scenario: fix a complex bug with two possible repair strategies
Create a team:
- Teammate A: implement solution 1
- Teammate B: implement solution 2
- Teammate C: evaluate the pros and cons of both
Both solutions can be implemented and tested in parallel, and the better one can be chosen afterward.
Documentation generation
When you need to produce a large amount of documentation:
Scenario: write documentation for the whole project
Create a team:
- Teammate A: write API documentation
- Teammate B: write the deployment guide
- Teammate C: write the development guide
- Teammate D: write the troubleshooting manual
Multiple documents can be written at the same time, greatly improving efficiency.
Simple modification tasks
Not suitable: variable renaming, single bug fixes, tiny feature additions
For these tasks, the cost of starting a team is greater than the actual work.
Highly serial tasks
Not suitable: tasks that must happen strictly in sequence
If task B cannot start until task A finishes, there is no real space for parallelism.
Cost-sensitive tasks
Agent Teams consumes 2 to 4 times the tokens of a single instance, depending on the team size. If cost is the primary concern, a single instance may be the better choice.
Are there multiple independent subtasks?
│
├─ No → Use a single instance
│
└─ Yes →
│
Can the subtasks be assigned to different files?
│
├─ No → Consider serial execution or split the task further
│
└─ Yes →
│
Is the cost acceptable (2-4x)?
│
├─ No → Use a single instance
│
└─ Yes → Use Agent Teams ✓
Using Agent Teams increases cost, but it can also produce significant efficiency gains. Understanding this tradeoff helps you make informed decisions.
Token consumption and team size
The token consumption of Agent Teams is roughly linear with team size:
| Team size | Relative cost | Suitable scenario |
|---|---|---|
| 1 person (single instance) | 1x | Simple tasks |
| 2-person team | 2-2.5x | Medium complexity |
| 3-person team | 3-4x | Complex tasks |
| 5+ person team | 5-6x+ | Large projects |
Why it is not perfectly linear:
Concrete example numbers (Claude 4.5 Sonnet):
Suppose a task requires:
The same task on a single Sonnet instance:
Cost multiplier: about 10x
But time saved: potentially reduced from 3 hours to 1 hour
Anthropic internal testing data:
Real case:
Anthropic's engineering team once used 16 parallel agents to build a C compiler in about 2 weeks that could compile the Linux 6.9 kernel, around 100,000 lines of Rust code, and it passed 99% of GCC tests.
Strategy 1: mix models
Team Lead: Opus (strong reasoning needed)
Teammates: Sonnet (high value for cost)
Simple tasks: Haiku (cheapest)
Strategy 2: adjust team size dynamically
Analysis phase: 5-person team (multi-angle analysis)
Implementation phase: 3-person team (parallel coding)
Testing phase: 2-person team (testing and fixing)
Strategy 3: use Agent Teams only in selected phases
Do not use Agent Teams for the entire project. Use it only in the most complex phases:
Phase 1 (requirements analysis): single instance
Phase 2 (architecture design): Agent Teams (multiple plans explored in parallel)
Phase 3 (coding): single instance
Phase 4 (code review): Agent Teams (multi-angle review)
Phase 5 (documentation): Agent Teams (parallel writing)
Worth it when:
Not worth it when: