Give one agent twelve tools and a four page instruction block and it starts guessing. I watched a support assistant that had to answer billing questions, look up orders, check shipping, and file a refund all from a single Bedrock agent. It worked in the demo. In production it picked the wrong action group about one call in six, because the model was choosing between too many jobs at once with no clear boundary between them.

Splitting that one agent into a small team fixed it. A supervisor agent reads the request and hands it to a specialist that does one thing. Part 13 built a single Bedrock agent with action groups. This part is about what happens when one agent is no longer enough, how Amazon Bedrock lets a supervisor coordinate collaborator agents, and the cost you pay in latency and tokens for the accuracy you gain.

What multi-agent collaboration means on Bedrock

Multi-agent collaboration lets several Amazon Bedrock agents work on one request together, coordinated by a supervisor. You designate one agent as the supervisor and associate one or more collaborator agents with it. When a user prompt arrives, the supervisor reads it, decides which collaborators are needed, builds a plan, sends each collaborator its piece, and stitches the responses into one answer. Every agent on the team, the supervisor included, is a normal Bedrock agent, so each keeps its own action groups, its own knowledge base for retrieval augmented generation, which is grounding answers in your own data, and its own guardrails from Part 14.

The reason to split is boundaries. A single agent choosing among a dozen tools has to hold every job in one instruction block, and the model degrades as that block grows. Give each collaborator one narrow role and a short instruction, and the supervisor only has to answer an easier question: which specialist does this belong to. That is a routing decision, not a twelve way tool choice, and models are far more reliable at it. The mortgage assistant in the AWS docs is the canonical shape: a supervisor that decides existing mortgage, new mortgage, or general question, and three collaborators that each own one of those.

Supervisor mode or supervisor with routing

Bedrock gives the supervisor two ways to behave, and you pick one when you configure it. In supervisor mode the supervisor always plans. It breaks the request into sub-tasks, sends them to the right collaborators, lets them run in parallel or in sequence, and consolidates every response into a final answer. That full planning pass is what you want for genuinely multi-step requests, where one question really does need billing and orders and shipping all consulted before an answer makes sense.

Supervisor with routing is the cheaper reflex. When the intent is clear, the supervisor routes the request straight to a single collaborator and skips the planning overhead entirely. Only when the request is complex, or when no clear intent is detected, does it fall back to the full supervisor pass. Most real traffic is simple, so routing mode keeps the common case fast and cheap and reserves the expensive orchestration for the requests that actually need it. My rule: start every team in routing mode, and only move a workload to always-plan supervisor mode if you can show that most of its requests truly need several collaborators at once.

When does a second agent actually help?

Not as often as the pattern gets reached for. A team of agents earns its cost in three situations. The first is genuine domain separation, where the jobs need different tools, different knowledge bases, or different guardrails, and cramming them into one agent muddies all three. The second is parallel work, where a request fans out into independent sub-tasks that can run at the same time, so several collaborators shorten wall clock time instead of just adding hops. The third is team ownership, where different teams own different agents and you want to compose them without merging their code or their access.

When none of those hold, a single agent with a few well described action groups is faster, cheaper, and easier to debug, and you should stay there. I have seen teams reach for a supervisor because it sounds more capable, then spend a week chasing why an answer is slow, when the real problem was three model hops where one would have done. If your request is one intent handled by one tool, adding a supervisor buys you nothing but latency and a bigger bill. Split when the boundaries are real, not because a team of agents reads well on a diagram.

Wiring a supervisor to its collaborators

The order matters here and trips people up. You must create and save the supervisor agent before you can associate any collaborator, because the association attaches to a saved supervisor. So the flow is: build each collaborator as an ordinary agent and note its alias, create the supervisor with collaboration turned on, associate each collaborator by its alias with a short collaboration instruction, prepare the supervisor, then invoke it. The example uses the bedrock-agent control plane to set the mode and associate one collaborator, and the bedrock-agent-runtime client to invoke.

import boto3

agent = boto3.client("bedrock-agent")
runtime = boto3.client("bedrock-agent-runtime")

# 1. create the supervisor with routing enabled, then save it
sup = agent.create_agent(
    agentName="support-supervisor",
    agentResourceRoleArn="arn:aws:iam::123456789012:role/BedrockAgentRole",
    foundationModel="anthropic.claude-3-5-sonnet-20240620-v1:0",  # [VERIFY current model id
    instruction="Route billing, order, and refund questions to the right specialist.",
    agentCollaboration="SUPERVISOR_ROUTER",  # or SUPERVISOR, or DISABLED [VERIFY enum]
)
sup_id = sup["agent"]["agentId"]

# 2. associate a saved collaborator agent alias with the supervisor
agent.associate_agent_collaborator(
    agentId=sup_id,
    agentVersion="DRAFT",
    agentDescriptor={"aliasArn": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/BILLING/LIVE"},
    collaboratorName="billing",
    collaborationInstruction="Owns billing and invoice questions only.",
)

# 3. prepare the supervisor so the change takes effect
agent.prepare_agent(agentId=sup_id)

# 4. invoke the supervisor; it routes to the billing collaborator
resp = runtime.invoke_agent(
    agentId=sup_id,
    agentAliasId="TSTALIASID",
    sessionId="demo-session-1",
    inputText="Why was I charged twice this month?",
)
for event in resp["completion"]:
    if "chunk" in event:
        print(event["chunk"]["bytes"].decode())

Expected output: create_agent returns an agentId, associate_agent_collaborator returns the collaborator association, prepare_agent moves the supervisor to PREPARED, and invoke_agent streams the billing collaborator's answer as decoded chunks.

Failure mode: a ValidationException if you try to associate a collaborator before the supervisor is saved, or if agentCollaboration is left DISABLED. A ResourceNotFoundException if the collaborator alias ARN is wrong or points at an unprepared agent. Confirm the exact enum values, the associate call signature, and the current model id against the bedrock-agent API before you script this. [VERIFY API field names and model id]

What it costs to run a team of agents

There is no line item for multi-agent orchestration. Bedrock does not charge you for the supervisor coordinating, for the routing decision, or for the plan. You pay for exactly one thing: the model invocations every agent makes, input tokens plus output tokens, at each agent's model rate. That sounds cheap until you count the hops. In full supervisor mode a single user question can trigger a planning call on the supervisor, a call on each collaborator it fans out to, and a consolidation call on the supervisor that reprocesses all the collaborator output. Every one of those is billed.

The practical read: routing mode is the default because it keeps the common request near a single agent cost, and full supervisor mode is a deliberate choice you make for the workloads that need it. Give the supervisor a smaller, cheaper model than the collaborators where the supervisor only routes, since routing is an easy task and you are paying for it on every request. And set a hard cap on how many collaborators a supervisor can fan out to, because an unbounded plan is an unbounded bill.

Agents Classic, AgentCore, and which to build on now

This is the part that changes the recommendation in 2026, and it is easy to miss. The native Bedrock Agents service that everything above is built on has been renamed Amazon Bedrock Agents Classic, and it closes to new customers on 30 July 2026. If your account has not used it, you are nearly out of the window to start on it. That does not delete existing agents, but it is a clear signal about where AWS is investing, and it should stop you from building a brand new estate on the Classic path today.

Where AWS is pointing is Amazon Bedrock AgentCore, which reached general availability in late April 2026. AgentCore is a serverless platform for hosting and running agents built in any framework, on any model, with a Runtime that supports sessions up to 8 hours for long agent work. For multi-agent specifically, it leans on open protocols rather than a fixed supervisor object: agents talk to other agents and to tools through the Model Context Protocol, MCP, which standardizes how an agent calls a tool, and Agent to Agent, A2A, which standardizes how two agents talk. That is a different shape from the managed supervisor and collaborator model, more building blocks and less turnkey, and Part 13 covered the start of that shift.

Two collaborators before you build a network

Here is the verdict I give teams. Split a single agent into a team when the boundaries are real, when different jobs need different tools, knowledge, or guardrails, or when work fans out into parallel sub-tasks. Start in supervisor with routing mode so the easy majority of requests stay near a single agent cost, and reserve full supervisor mode for the workloads you can show actually need several agents at once. Keep collaborator roles from overlapping, give the supervisor a cheaper model when it only routes, and put a hard cap on fan out so one plan cannot run up ten model calls.

Do not start with a network of ten agents. Start with a supervisor and two collaborators, prove the routing is picking the right specialist by reading the trace, and add a third only when a measured request genuinely needs it. And if you are building this new in 2026, prototype on AgentCore rather than on the Classic path that is closing to new customers, because the pattern is the same and the platform is where AWS is headed.

Part 22 turns from agents you build to agents AWS ships, with Amazon Q Business and Q Developer, where the multi-agent plumbing is hidden and you consume the result. If you work across clouds, the same supervisor and specialist pattern appears as the Azure AI Agent Service, and the guardrails that every one of these collaborators still needs are in Part 14 on Bedrock Guardrails. This week, take your most overloaded single agent, list its jobs, and draw the two or three boundaries where a specialist would own each cleanly. That drawing tells you whether a team is worth building, before you spend a token on it.

References

• Use multi-agent collaboration with Amazon Bedrock Agents
• Amazon Bedrock announces general availability of multi-agent collaboration
• Create multi-agent collaboration
• Amazon Bedrock AgentCore

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts