Multi-Agent Collaboration in Bedrock Agents
How Amazon Bedrock implements supervisor and router collaboration natively, using agent aliases, collaboration instructions and a single InvokeAgent call.
Amazon Bedrock Agents supports multi-agent collaboration as a managed feature, so you do not have to write the delegation loop yourself. You designate one agent as a supervisor and associate one or more existing agents with it as collaborators. At runtime you call InvokeAgent on the supervisor only; Bedrock handles the routing, the sub-invocations and the aggregation.
How you wire it up
The collaboration mode is set on the supervisor via the agentCollaboration field when you create or update it:
SUPERVISOR— the supervisor reasons about the request, may break it into sub-tasks, may consult several collaborators, and composes the final answer.SUPERVISOR_ROUTER— the supervisor first attempts to classify the request and route it straight to a single collaborator, which is cheaper and lower latency. If the request is too complex or ambiguous to classify, it falls back to full supervisor behaviour.DISABLED— an ordinary single agent.
You then call AssociateAgentCollaborator for each collaborator. Two details matter. First, you associate an agent alias ARN, not an agent ID — so each collaborator must already be prepared and have an alias. That gives you version pinning: the supervisor talks to a specific published version of the collaborator, and updating a collaborator's draft does not silently change the supervisor's behaviour until you point the alias at the new version. Second, the collaborationInstruction is what the supervisor uses to decide when to delegate. Treat it exactly like a tool description: say what this collaborator handles and what it does not.
relayConversationHistory controls whether the collaborator sees the conversation so far (TO_COLLABORATOR) or only the sub-task the supervisor writes for it (DISABLED). Relaying helps with pronouns and follow-ups; it also multiplies your input tokens on every hop, and it hands the collaborator any untrusted text the user pasted earlier. Default to DISABLED and turn it on deliberately.
After any structural change you must call PrepareAgent on the supervisor and publish a new alias, exactly as with a single agent.
What stays the same
A supervisor is still a normal agent. It can have its own action groups, its own knowledge bases, its own guardrail and its own idleSessionTTLInSeconds. Collaborators are normal agents too — each keeps its own execution role, action groups and knowledge bases, which is where the permission isolation from the previous lesson comes from. Guardrails are configured per agent, so attaching one to the supervisor does not protect a collaborator.
What it is not
It is not a general workflow engine: the order of delegation is decided by a model each time, so two identical requests can take different paths. If you need a fixed sequence with retries and audit, that is Step Functions. It is also not the only option in Bedrock — InvokeInlineAgent lets you define an agent and its collaborators at request time without deploying them, which suits experimentation and per-tenant configurations, and Amazon Bedrock AgentCore lets you run agents built with open-source frameworks while still using managed memory, identity, gateway and observability.
Example
import boto3
ctrl = boto3.client("bedrock-agent")
rt = boto3.client("bedrock-agent-runtime")
# 1. The supervisor. Note agentCollaboration on the agent itself.
sup = ctrl.create_agent(
agentName="support-supervisor",
foundationModel="anthropic.claude-3-5-sonnet-20241022-v2:0",
agentResourceRoleArn="arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForAgents_supervisor",
instruction=(
"You are the front door for customer support. Delegate to a specialist "
"when one clearly applies. Never state a refund has been issued unless a "
"collaborator reported it. Always answer the customer yourself."
),
agentCollaboration="SUPERVISOR_ROUTER",
idleSessionTTLInSeconds=900,
)
supervisor_id = sup["agent"]["agentId"]
# 2. Associate collaborators BY ALIAS ARN (they must be prepared + aliased).
ctrl.associate_agent_collaborator(
agentId=supervisor_id,
agentVersion="DRAFT",
agentDescriptor={
"aliasArn": "arn:aws:bedrock:eu-west-1:111122223333:agent-alias/ABCDEFGHIJ/PROD1"
},
collaboratorName="research",
collaborationInstruction=(
"Use for order lookups and product documentation questions. "
"Do NOT use for refunds, credits or anything that changes an account."
),
relayConversationHistory="DISABLED",
)
ctrl.associate_agent_collaborator(
agentId=supervisor_id,
agentVersion="DRAFT",
agentDescriptor={
"aliasArn": "arn:aws:bedrock:eu-west-1:111122223333:agent-alias/KLMNOPQRST/PROD1"
},
collaboratorName="refunds",
collaborationInstruction=(
"Use ONLY when the customer asks for a refund and the order id is known. "
"Pass the order id explicitly."
),
relayConversationHistory="DISABLED",
)
# 3. Prepare, then publish an alias to invoke.
ctrl.prepare_agent(agentId=supervisor_id)
# 4. One call at runtime - the supervisor fans out internally.
response = rt.invoke_agent(
agentId=supervisor_id,
agentAliasId="LIVE01",
sessionId="session-8f2c",
inputText="Order 44821 arrived damaged. Can I get my money back?",
enableTrace=True,
)
for event in response["completion"]:
if "chunk" in event:
print(event["chunk"]["bytes"].decode(), end="")
elif "trace" in event:
# routing decisions and each collaborator's reasoning land here
print(event["trace"]["trace"])When to use it
- Fronting billing, technical-support and returns agents with one supervisor so the customer sees a single assistant.
- Using SUPERVISOR_ROUTER so simple, clearly-categorised questions skip the expensive decomposition step.
- Pinning each collaborator to a published alias so a change to one specialist cannot alter the supervisor's behaviour until you promote it.
Discussion