Phase 4: Multi-Agent Systems · 55 min · Python · OpenAI SDK · Anthropic SDK
When to Go Multi-Agent
A system that needs to be split isn't a failure — it's an architecture.
Hiring signal: The question 'Tell me about your multi-agent architecture and why you chose it' is common in AI engineer system design interviews. Candidates who can articulate concrete decision criteria — not just 'I used multi-agent because it seemed right' — demonstrate engineering judgment that separates senior candidates from junior ones.
What you will learn
- Apply three decision criteria for choosing multi-agent over single-agent architectures
- Identify the complexity, parallelism, and specialization triggers for multi-agent
- Estimate the overhead cost of multi-agent coordination and decide when it's justified
The Problem
One agent trying to do everything is an antipattern. The system prompt bloats, context windows fill up with unrelated tool definitions, and the model's reliability degrades. The fix isn't more instructions — it's the right architecture. The question isn't "can I do this in a single agent?" It's "should I?"
Multi-agent systems add coordination overhead: extra model calls, more tokens, more failure modes. They are only justified when you have concrete evidence they're needed. This lesson gives you the three triggers that justify the investment — and the anti-patterns that don't.
The Three Triggers for Multi-Agent
Every decision to go multi-agent should be driven by at least one of three concrete triggers.
Complexity trigger: The task exceeds one agent's reliable reasoning capacity. Rule of thumb: more than 15 distinct steps, or more than 20 tool definitions in a single agent, is a signal to consider splitting. When a context window fills with tool definitions for unrelated domains — email tools, database tools, web tools, calendar tools — the model struggles to choose correctly among them.
Parallelism trigger: Subtasks are independent and can run simultaneously. A research agent, a writer agent, and a reviewer agent can each start working as soon as they have their input — they don't need to wait for each other. In a single-agent system, these run sequentially. Multi-agent with parallel execution can cut wall-clock time by 3–5× on tasks with independent branches.
Specialization trigger: Different subtasks need fundamentally different system prompts, tool sets, or even model choices. A code review agent needs a precise, detail-oriented persona with code analysis tools. A customer support agent needs an empathetic tone and CRM tools. Cramming both into one agent produces a system that's mediocre at both. Each trigger can justify multi-agent independently — you don't need all three.
A team wants to build an agent that: (1) scrapes competitor prices, (2) analyzes market position, (3) drafts a pricing recommendation email. Should this be single-agent or multi-agent?
Apply the three triggers: Complexity? No — 3 steps is simple. Parallelism? No — steps 2 and 3 depend on step 1 sequentially. Specialization? Minor — all tasks can run with the same base model and similar tool sets. The coordination overhead of 3 agents would cost more (tokens, latency, complexity) than it saves. Single agent wins here.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers The Coordination Overhead Cost, Anti-Patterns: When People Go Multi-Agent Wrongly, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy