When One Agent Is Not Enough
Why you split work across several agents — specialisation, separate tool permissions and context isolation — and when a single agent is still the right answer.
A multi-agent system is a set of agents that each have their own instructions, their own tools, their own execution role and often their own model, coordinating on one user request. It exists because a single agent degrades as you keep adding to it. Every new tool you attach widens the choice the model has to make on every turn, and every new paragraph of instruction competes with the rest for the model's attention. At some point the cheapest fix is not a better prompt but a boundary.
The three reasons that actually justify a split
- Specialisation. An agent with six tools and a page of instructions picks the right tool far more reliably than an agent with forty tools and eight pages. Splitting a billing agent away from a technical-support agent gives each one a small, coherent decision space.
- Separate tool permissions. This is the strongest argument and the one the exam leans on. In Amazon Bedrock, each agent has its own service execution role and its own action groups. A research agent whose role has no
lambda:InvokeFunctionpermission for the refund function cannot issue a refund — not because you told it not to, but because the call fails at IAM. Prompt instructions are guidance; IAM is a boundary. If two parts of your workload need genuinely different blast radii, they belong in different agents. - Context isolation. A sub-agent can read a 400-page runbook, a noisy log dump or twenty search results, and return three sentences. The parent's context window never sees the raw material. This keeps the parent's reasoning sharp and its per-turn cost flat, because an agent re-sends its whole conversation on every model invocation.
What multi-agent is not
It is not a fix for a badly written prompt. If a single agent is choosing the wrong tool because two tool descriptions overlap, splitting it into two agents just moves the ambiguity into the supervisor's delegation decision. Fix the descriptions first.
It is not free parallelism either. Under a supervisor pattern the coordination itself is model-driven, so every delegation is an extra round trip and an extra set of billed tokens. And it is not a substitute for a workflow: if the steps are known in advance and always run in the same order, that is a Step Functions state machine, not a committee of agents.
A rule of thumb
Start with one agent. Split when you can state the boundary in one sentence — "this part needs write access to production and that part does not", or "this part chews through huge documents and the rest should not have to see them". If the best sentence you can produce is "it feels big", you are not ready to split, and you will pay for the extra hops without getting anything back.
Example
// Two Bedrock agents, deliberately given different blast radii.
// The boundary is the execution role, not the instruction text.
{
"researchAgent": {
"agentName": "support-research",
"foundationModel": "anthropic.claude-3-5-sonnet-20241022-v2:0",
"agentResourceRoleArn": "arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForAgents_research",
"instruction": "You look up order history and product documentation. You never promise a refund or a credit; you report facts and hand them back.",
"actionGroups": ["lookup-order", "search-docs"],
"knowledgeBases": ["product-manuals-kb"],
"// role policy": "lambda:InvokeFunction on lookup-order + search-docs ONLY; bedrock:Retrieve on the KB"
},
"refundAgent": {
"agentName": "support-refunds",
"foundationModel": "anthropic.claude-3-5-haiku-20241022-v1:0",
"agentResourceRoleArn": "arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForAgents_refunds",
"instruction": "You issue refunds up to the limit enforced by the issue-refund function. Always state the order id and amount in your reply.",
"actionGroups": ["issue-refund"],
"// role policy": "lambda:InvokeFunction on issue-refund ONLY"
}
}
// Prompt injection in a product review cannot make researchAgent
// issue a refund: the credential simply is not there.When to use it
- Splitting a customer-support assistant so that the agent reading untrusted user-supplied text has no permission to move money.
- Giving a document-heavy compliance reviewer its own agent so that thousands of pages of policy never enter the main conversation's context window.
- Running a cheap model for intent classification and a stronger model only for the agent that does the actual reasoning.
Discussion