When a single agent would be overwhelmed by trying to do everything, split into specialists. A supervisor agent classifies the task, dispatches to domain-expert agents (research, code, writing, etc.), and synthesizes their outputs into a final response. Each specialist has its own tools and knowledge.
The user request goes to a supervisor agent that classifies the task and routes subtasks to the right specialist agent(s). Each specialist has its own tools, knowledge base, and (optionally) its own foundation model — tuned for a specific domain. Specialists can run in parallel when subtasks are independent, or sequentially when one feeds the next. Their results flow back to the supervisor, which synthesizes a final response.
On AWS, AWS Agent Squad is the framework for coordinating multiple specialized agents. You can also build this with a Bedrock Agent as the supervisor and additional Bedrock Agents (or Strands Agents) as specialists.
Bedrock AgentsCan serve as the supervisor, the specialists, or both. Each agent has its own action groups and knowledge bases.
Strands AgentsOpen-source framework. Use for specialists needing custom reasoning logic the managed service can't provide.
Step FunctionsAlternative orchestrator. Use Step Functions as supervisor when coordination needs deterministic branching or parallel fan-out across many specialists.
LambdaTools for each specialist's action groups.
Bedrock Knowledge BasesEach specialist can have its own KB — e.g., research agent on the internal docs, code agent on code examples.
When to use this pattern
✓ Use Multi-Agent when…
The task spans multiple clear expertise domainsResearch + analysis + writing. Research + code. Diagnosis + treatment recommendation + billing. Each specialist focuses on what it's good at.
A single agent's prompt would be overwhelmingCramming "you are a researcher, a coder, AND a writer" into one system prompt degrades performance. Split into focused specialists.
Specialists can benefit from different FMsUse a reasoning model for research, a code-tuned model for generation, a smaller fast model for routing. Multi-agent lets you mix.
Subtasks can run in parallelResearch agent and code agent work simultaneously. Big latency win vs. a single agent doing both sequentially.
You need specialized tool sets per domainResearch agent has Kendra + KB access; code agent has GitHub + CI/CD access. Keeping tool sets scoped per specialist is cleaner and safer.
✗ Do NOT use Multi-Agent when…
A single agent could handle the taskOverkill. Multi-agent adds coordination overhead, latency, and cost. Start with Pattern 3 and split only if needed.
The workflow is deterministic branchingUse Step Functions directly — no FM reasoning needed for known-path workflows.
Tight latency budgetsSupervisor + multiple specialists = many FM calls per request. Latency compounds.
Cost is a hard constraintEvery agent hop is additional tokens. Multi-agent can be 3-5x the cost of a single agent for the same task.
Tasks are strongly interdependent at every stepIf specialists must coordinate constantly, the overhead exceeds the benefit. A single agent with all tools is cleaner.
Debugging must be simpleTracing multi-agent workflows is harder than single-agent. More moving parts = more places things can go wrong.
Exam angle
Pattern-match shortcuts
When a stem mentions "multiple specialized tasks,""coordinate different expertise areas," or "research and writing and review," the answer is AWS Agent Squad or multiple Bedrock Agents with a supervisor.
The "more agents = better" trap
Multi-agent is NOT a default upgrade. The exam rewards picking the simplest pattern that satisfies requirements. If a single agent with more tools would work, that's the right answer — multi-agent is only correct when the stem explicitly implies specialization or multi-domain coordination.
Start with Pattern 3: Single Agent before considering multi-agent.
If coordination is deterministic, use Step Functions rather than a supervisor agent.
For full safety on multi-agent deployments: Pattern 10: Defense-in-Depth.