← 19.219.4 →
2337 words No Slides

Video 19.3: When to Use Multi-Agent vs Single Agent

Course: Claude Code - Parallel Agent Development (Course 4) Section: 19 - Multi-Agent Fundamentals Video: 19.3 of 4 Duration: 4-5 minutes Presenter: Daniel Treasure

Opening Hook

"Multi-agent development isn't always better. Running four agents in parallel costs four times the tokens, uses four times the resources, and introduces coordination overhead. The question isn't 'can we parallelize?' but 'should we?' Understanding when to say no is as important as knowing when to say yes."

Key Talking Points

The Core Decision Framework

What to say: - Before spinning up a team, ask three simple questions - First: Is the work decomposable? Can you break it into independent modules with minimal overlap? - Second: Are the subtasks truly independent, or does one depend on another being complete first? - Third: Does the speed gain justify the cost and complexity overhead? - If you can answer yes to all three, multi-agent might be the right choice

What to show on screen: - A decision tree or flowchart on screen: - Is it decomposable? (Yes → Continue, No → Single Agent) - Are subtasks independent? (Yes → Continue, No → Single Agent) - Does speed matter more than cost? (Yes → Multi-Agent, No → Consider trade-offs)

Good Use Cases for Multi-Agent

What to say: - New features or modules being built from scratch - Example: Building a new microservice with frontend, API, database, and tests - Each can be worked on independently if you define the contracts clearly upfront

  • Cross-layer development
  • Frontend team, backend API team, database schema team working simultaneously

  • They rely on shared interfaces, but once those are defined, they can run in parallel

  • Debugging competing hypotheses

  • You think the bug might be in the parser or the optimizer
  • Send one agent to investigate the parser, another to investigate the optimizer

  • Reduces time to root cause from sequential trial-and-error to parallel exploration

  • Large-scale refactoring

  • You're refactoring a monolithic codebase into microservices
  • Agent A refactors module 1, Agent B refactors module 2, etc.

  • Much faster than doing it sequentially

  • Research and review

  • One agent researches best practices for performance optimization
  • Another agent reviews existing code for vulnerabilities
  • A third agent updates documentation

  • All happening in parallel

  • Documentation and tests alongside implementation

  • As the main agent writes features, a subagent writes tests
  • Another subagent updates documentation
  • No blocking, all parallel

What to show on screen: - Show examples of each use case with simple diagrams or code snippets - Highlight the key word for each: "Independent," "Parallel," "Non-blocking"

Bad Use Cases for Multi-Agent (Avoid These)

What to say: - Sequential task dependencies - You can't write the API tests until the API exists - You can't write the frontend until the API contracts are finalized - If each step depends on the previous one, parallelization won't help - Multi-agent overhead actually slows you down

  • Multiple agents editing the same files
  • This is a recipe for merge conflicts and lost work
  • If your task requires coordinating edits to the same file, use single agent

  • Or use a version control merge strategy, but that adds complexity

  • Heavily interdependent modules

  • You're building a tightly-coupled system where changes in module A break module B
  • Agents spend more time coordinating and fixing conflicts than benefiting from parallelization

  • Better to keep it single-agent and handle the tight coupling in one context

  • When token budget is constrained

  • If you have limited API budget, multi-agent is wasteful
  • One agent working slower is cheaper than four agents working in parallel

  • Consider your constraints: budget > speed in this case

  • Small, focused tasks

  • "Add a button to the UI" doesn't benefit from three agents
  • The overhead of coordination exceeds the benefits
  • Keep it simple, use single agent

What to show on screen: - Show failure scenarios: two agents editing the same file (merge conflict), sequential task dependency (Agent B blocked waiting for Agent A), small task with large overhead (overkill) - Use red X marks or warning icons to emphasize "don't do this"

The "Team Meeting" Heuristic

What to say: - Here's a simple rule of thumb: if your real-world team would need a team meeting to hand off work, you probably need multi-agent - If you're dividing the work such that different people/agents can work independently, that's a signal multi-agent could work - Conversely, if your real-world team could do this in a single session with one person coding, single-agent is probably fine - This heuristic isn't perfect, but it's a good gut check

What to show on screen: - Show a team meeting scenario: "Frontend team, you own the UI. Backend team, you own the API. Database team, you own the schema. Everyone work in parallel and sync tomorrow." - Then show a single-person scenario: "Add dark mode to the dashboard. It's all in one file." - Emphasize: Multi-agent for the first, single-agent for the second

Cost Implications

What to say: - Multi-agent development typically costs 4-15x more tokens than single-agent for the same task - This is because each agent has its own context window running simultaneously - The trade-off: you might complete the task in 1/4 the time, but at 4x the token cost - Is 4 hours of work worth 4x the API cost? Depends on your priorities - For companies: money might be less important than time-to-market - For indie developers or startups: cost might be the limiting factor - The C compiler case study achieved efficiency through exceptional task decomposition; that's not always possible

What to show on screen: - Show a simple cost comparison chart: - Single-agent: 100 hours work, 1M tokens, $15 - Multi-agent (4 agents): 25 hours work, 4M tokens, $60 - Savings: 75 hours time, cost 4x tokens - Label: "Time vs. Cost Trade-off"

Decision Tree Walk-Through

What to say: - Let's work through a few scenarios together to show how the decision framework plays out - Scenario 1: Building a REST API for a new feature - Is it decomposable? Database layer, API routes, error handling, tests - Are subtasks independent? Yes, they can be if you define schemas and routes upfront - Does speed matter? Maybe—if you're in a sprint with a deadline - Verdict: Multi-agent could work, but requires upfront planning

  • Scenario 2: Fixing a critical bug in production code
  • Is it decomposable? Maybe one hypothesis per agent
  • Are subtasks independent? Competing hypotheses, yes
  • Does speed matter? YES—bugs are urgent

  • Verdict: Multi-agent could save hours

  • Scenario 3: Refactoring a single file for better performance

  • Is it decomposable? Maybe—one agent optimizes, another writes benchmarks
  • Are subtasks independent? Somewhat—the benchmarks help validate optimization
  • Does speed matter? Low priority refactor
  • Verdict: Probably overkill, stick with single-agent

What to show on screen: - Walk through each scenario on screen, showing a decision tree or checklist - Mark up the answers: yes/no/maybe - Show the final verdict with a visual: Green checkmark for "Multi-Agent Approved," yellow caution for "Consider Trade-offs," red X for "Single-Agent"

Demo Plan

0:00–0:45 - Opening Scenario: The Task Assessment 1. Show a GitHub issue or feature request on screen 2. Read it aloud: "Build a search feature for our product: UI component, search API, indexing service, tests, documentation" 3. Say: "This sounds like a candidate for multi-agent. Let's see if it meets our criteria."

0:45–2:15 - Walking Through the Decision Framework 1. Apply the three questions to the search feature: - Is it decomposable? (Diagram the layers: UI, API, indexing, tests) - Are subtasks independent? (Show the contracts/interfaces between layers) - Does speed matter? (Assume yes for a competitive feature) 2. Conclude: "This is a good multi-agent candidate." 3. Switch scenarios: "But what if the issue said 'fix a performance bug in the indexing layer'?" - Decomposable? Not really—it's a single module - Independent? No, one agent investigating per hypothesis - Speed matters? Yes, but we'd only need 2-3 agents max - Verdict: Single-agent with maybe one research subagent

2:15–3:45 - Cost vs. Speed Trade-Off 1. Pull up the cost comparison chart 2. Show: "The search feature: 40 hours single-agent work, ~2M tokens, $30" 3. Multi-agent version: "4 agents in parallel, 10 hours elapsed, ~8M tokens, $120" 4. Ask: "Is finishing 30 hours earlier worth $90 extra in API costs?" 5. Show how the answer varies by context (startup vs. large company, deadline vs. backlog)

3:45–4:45 - Real Example: Make the Call 1. Present a new scenario (or use one from prep): "We're adding real-time notifications to our app" 2. Break down the task: WebSocket server, frontend listener, database tracking, notification service 3. Apply decision framework step-by-step on screen 4. Call it: "This is a YES for multi-agent" 5. Lead out with: "But how do you actually set it up? That's what video 19.4 covers."

Code Examples & Commands

Example Task Breakdown for Multi-Agent Approval

## Feature: Real-Time Notifications

### Task Decomposition
- [ ] WebSocket Server (Agent: Backend)
- [ ] Database Schema for notifications (Agent: Database)
- [ ] Frontend WebSocket Client (Agent: Frontend)
- [ ] Notification Service Logic (Agent: Services)
- [ ] Test Suite (Agent: QA)
- [ ] Documentation (Agent: Docs)

### Independence Check
- Backend and Database: Independent after schema is defined
- Frontend and Backend: Independent after API contract is defined
- Service and Database: Independent after data model is defined
- All others: Can run in parallel

### Verdict: APPROVED for Multi-Agent

Example Task Breakdown for Single-Agent Decision

## Task: Fix Memory Leak in Garbage Collector

### Task Decomposition
- [ ] Locate the leak using profiler
- [ ] Identify root cause (likely sequential investigation)
- [ ] Implement fix
- [ ] Verify with benchmarks

### Independence Check
- Leak location depends on profiling
- Fix depends on knowing the cause
- Verification depends on fix being complete
- Inherently sequential

### Verdict: SINGLE-AGENT ONLY

Cost Comparison Script

# Token calculation (approximate)
# Single-agent: 40 hours work = ~2M tokens
# Multi-agent (4 agents): 10 hours = 4x2M tokens in parallel

# Cost assuming $10 per 1M tokens
SINGLE_AGENT_TOKENS=2000000
MULTI_AGENT_TOKENS=8000000
PRICE_PER_M_TOKENS=10

single_agent_cost=$(echo "scale=2; $SINGLE_AGENT_TOKENS / 1000000 * $PRICE_PER_M_TOKENS" | bc)
multi_agent_cost=$(echo "scale=2; $MULTI_AGENT_TOKENS / 1000000 * $PRICE_PER_M_TOKENS" | bc)

echo "Single-agent cost: \$$single_agent_cost"
echo "Multi-agent cost: \$$multi_agent_cost"
echo "Cost increase: $(echo "scale=2; $multi_agent_cost / $single_agent_cost" | bc)x"

Gotchas & Tips

Gotcha: The Temptation to Over-Parallelize

  • It's exciting to spin up multiple agents
  • Resist the urge to parallelize tasks that don't benefit from it
  • Always ask: "Does this actually need parallelization?"

Tip: Upfront Design Is Critical

  • Before launching multiple agents, define interfaces and contracts clearly
  • If you're vague about who owns what, you'll have coordination nightmares
  • Spend time on architecture before code

Gotcha: Coordination Overhead Is Often Underestimated

  • Agents need to sync status, approve plans, handle conflicts
  • This overhead can eat into the speed gains
  • If tasks have high interdependence, the overhead multiplies

Tip: Start with One Agent, Scale Up Cautiously

  • Build the feature with one agent first
  • Once it works, consider how it could be parallelized
  • Use that learnings to make the multi-agent version more efficient

Gotcha: Token Cost Can Surprise You

  • Running 4 agents for 2 hours is expensive (multiple context windows)
  • Budget constraints are real
  • Always compute the cost impact before committing

Tip: The "Team Meeting" Heuristic Works

  • If you'd naturally divide this work among team members, multi-agent fits
  • If one person could do it alone easily, single-agent is the move
  • Simple rule, but surprisingly accurate

Tip: Measure the Actual Gain

  • After a multi-agent project, measure: time saved vs. tokens used
  • Did you actually finish faster? Was it worth the cost?
  • Use this data to improve future decisions

Lead-Out

"So you've got a decision framework, some good and bad use cases, and a way to think about cost vs. speed. The question most of you are probably asking now is: 'Okay, I've decided to go multi-agent. How do I actually set this up?' That's the final video in this section. We'll walk through environment setup, configuration, and getting your first multi-agent team up and running. Let's build something."

Reference URLs

Prep Reading

  • Review cost calculator for Claude API
  • Read case studies about teams that scaled from single-agent to multi-agent
  • Think about your own projects: which would have benefited from parallelization?
  • Understand token consumption patterns (how many tokens per hour of work?)
  • Review scheduling and coordination overhead concepts from distributed systems literature

Notes for Daniel

This video is about making smart choices, not blind advocacy for multi-agent. The tone should be balanced: "Multi-agent is powerful, but not a magic bullet." Help viewers develop judgment.

The decision framework should feel intuitive and easy to remember. The viewer should leave thinking, "Okay, next time I tackle a task, I'll ask these three questions."

Use real-world analogies: team meetings, task boards, project planning. These concepts map well to multi-agent architecture and help viewers think in the right way.

The scenarios demo should feel natural, like you're thinking through a feature request the way a project manager would. The verdict should be matter-of-fact, not preachy.

Time management: Hook (30s), decision framework (1:30), use cases (1:00), cost discussion (1:00), scenarios (1:00), lead-out (30s). Be flexible; if a scenario resonates, spend extra time on it.

Tone: You're a pragmatist, not a cheerleader. The best choice is often "single-agent," and that's fine.