AWS Builder Center

Builder Center

Introducing the AWS Guidance for Multi-Agent Orchestration using Amazon Bedrock AgentCore

A single AI agent can answer a question, but real customer journeys need several agents working together. This post introduces the Guidance for Multi-Agent Orchestration using Amazon Bedrock AgentCore, a deployable solution that pairs a supervisor agent with specialized sub-agents on serverless AgentCore infrastructure. It covers session isolation, end-to-end identity, shared memory, MCP-based tool access, and observability, so builders can focus on agent logic instead of infrastructure

Sreedevi Velagala

Generative AI has moved past the single chatbot. Teams now build agentic systems where one agent plans the work, hands tasks to others, calls tools, remembers context, and puts together an answer. Customer support is a common example. One conversation can include an order status check, a troubleshooting question, a personalized product recommendation, and an inventory lookup, and each of those is a different domain with its own data, tools, and prompts.
Splitting this work across specialized agents can improve accuracy, keeps prompts focused, and lets each agent use a model sized for its job. It also raises hard engineering questions. Where do the agents run, and how are user sessions isolated? How does user identity travel safely from the frontend through the supervisor to every sub-agent and tool? How does the system remember what a customer said last week? How do you see which agent did what when something goes wrong?
To help with this, AWS offers the  Guidance for Multi-Agent Orchestration on AWS , part of the  AWS Solutions Library . It includes several orchestration patterns. This post covers the Amazon Bedrock AgentCore implementation, which uses AgentCore's managed Runtime, Memory, Gateway, Identity, and Observability together with the open-source Strands Agents SDK. It's written for developers, architects, and engineers who want a starting point for taking multi-agent systems to production on AWS.

The Multi-Agent Challenge: Why Managed Orchestration Matters

Multi-agent architectures help, but building one from scratch creates a predictable set of problems:
  • Infrastructure overhead: Each agent needs a place to run, scale, and recover. Teams often build container clusters, autoscaling policies, and load balancers for every agent before they write any agent logic.
  • Session isolation and security: Agents act on customer data. Without strong isolation, one user's context could leak into another user's session. Each hop (frontend to supervisor, supervisor to sub-agent, sub-agent to tool) is another trust boundary to secure.
  • Identity propagation: The supervisor knows who the user is, but sub-agents and backend tools need that identity too. If the LLM carries the user ID through a prompt, a hallucination can cause data from the wrong customer to be returned.
  • Context and memory: Customers expect the system to remember what they said earlier in the conversation and in past ones. Building short-term and long-term memory, including extracting facts and preferences, takes a lot of custom work.
  • Tool integration sprawl: Each agent needs access to APIs, databases, and Lambda functions. Without a standard interface, every integration is custom glue code.
  • Observability gaps: When a supervisor delegates to four sub-agents and each calls several tools, debugging without end-to-end tracing is mostly guesswork.
Together, these problems slow teams down and keep promising agent prototypes from reaching production. A managed agent platform addresses them by handling runtime, memory, identity, tools, and observability as shared capabilities.

AWS Guidance for Multi-Agent Orchestration using Amazon Bedrock AgentCore

AWS Guidance provides prescriptive technical expertise, reference architectures, best practices, and deployable code samples to speed up cloud solutions. This Guidance gives you a  ready-to-deploy solution  that shows how to build, secure, and run a multi-agent system end to end.
It's built on two parts:
  • Amazon Bedrock AgentCore: A secure, serverless runtime for deploying and scaling AI agents with any open-source framework or model. AgentCore runs each user session in its own dedicated microVM, scales to thousands of sessions in seconds, and works with leading identity providers. Its managed services (Runtime, Memory, Gateway, Identity, and Observability) replace infrastructure that teams would otherwise build and run themselves.
  • Strands Agents SDK: An open-source, model-driven framework for building agents in Python with minimal code. Strands integrates directly with AgentCore. For example,  AgentCoreMemorySessionManager  connects memory without custom code, and the "Agents as Tools" pattern lets a supervisor call sub-agents the way it would call functions.
Deployment uses the AWS CDK (TypeScript), and a single script provisions the infrastructure, agents, knowledge bases, and frontend. You get more than sample agent code. You get a complete reference implementation that combines security, memory, tools, and monitoring, which saves the work of wiring these together yourself.

Use Case: Intelligent Customer Support

The Guidance shows these capabilities through a retail customer support assistant. A Supervisor Agent coordinates four specialized sub-agents:
Agent
Responsibility
Supervisor Agent
Central orchestrator. Analyzes intent, delegates tasks, and combines the responses
Order Management Agent
Order status, shipment tracking, and inventory queries
Product Recommendation Agent
Product search and recommendations across sponsored and organic results
Personalization Agent
Recommendations based on customer profile and browsing history
Troubleshooting Agent
Step-by-step technical support using FAQs and troubleshooting guides

Architecture Overview

At the core of the architecture is a Supervisor Agent running on Amazon Bedrock AgentCore Runtime. It routes each customer request to the right specialist, and each specialist runs in its own AgentCore Runtime. All agents are built with Strands, packaged as ARM64 containers in Amazon ECR, and deployed as separate runtimes, so each one scales and is secured independently.


Request Flow and AWS Service Integration

A typical request goes through the architecture like this:
  1. User access and authentication: The user opens the React web application through Amazon CloudFront, which is protected by AWS WAF and serves static content from an Amazon S3 bucket. Amazon Cognito authenticates the user and issues a JWT bearer token.
  1. Direct-to-runtime streaming: The frontend sends requests with the JWT straight to the AgentCore Runtime endpoint for the Supervisor Agent, using Server-Sent Events (SSE) to stream responses in near real time. No API gateway or Lambda proxy sits in between.
  1. Token validation: AgentCore Runtime validates the JWT against Cognito's OIDC discovery endpoint before the request reaches the Supervisor Agent container.
  1. Supervisor orchestration: The Supervisor Agent (Strands, using Claude Sonnet 4.5 on Amazon Bedrock) extracts the user identity from the JWT, looks up the  customer_id  from the user's Cognito attributes, loads conversation context from AgentCore Memory, analyzes the query, and decides which sub-agent or sub-agents to call.
  1. Sub-agent invocation: The supervisor calls each sub-agent through the Strands "Agents as Tools" pattern. Each call passes:
  • The same JWT in the Authorization header, which the sub-agent's Runtime validates again
  • The  customer_id  in the payload, set by code rather than by the LLM, so data isolation doesn't depend on model output
  1. Domain processing: Each sub-agent (running Claude Haiku 4.5 for lower cost and faster responses) handles its part of the task:
  • Order Management: Queries orders and inventory through AgentCore Gateway tools
  • Product Recommendation: Searches sponsored and organic product catalogs through Gateway
  • Personalization: Retrieves the customer profile and browsing history from an Amazon Bedrock Knowledge Base using RAG
  • Troubleshooting: Retrieves FAQs, troubleshooting guides, and warranty information from a Knowledge Base using RAG
  1. Tool access through MCP: Each specialist has its own AgentCore Gateway, which exposes AWS Lambda functions as Model Context Protocol (MCP) endpoints. The Gateway validates the JWT again before it runs any tool.
  1. Knowledge retrieval: Knowledge Bases use Amazon Titan Text Embeddings v2 and Amazon OpenSearch Serverless vector collections for semantic search.
  1. Response aggregation: Sub-agents return results to the supervisor, which combines them into one answer, stores the interaction in AgentCore Memory, and streams the answer back to the user over SSE.
  1. Observability: AgentCore Observability records agent performance, conversation flows, tool usage, and error rates using OpenTelemetry. Amazon CloudWatch stores detailed execution traces for debugging and tuning.
This design relies on managed services throughout. CloudFront and WAF handle edge delivery and protection, Cognito handles identity, AgentCore Runtime provides isolated serverless compute, AgentCore Memory keeps context, AgentCore Gateway standardizes tool access, Bedrock and Knowledge Bases provide models and retrieval, and CloudWatch provides visibility. AWS Systems Manager Parameter Store holds runtime configuration, and AWS KMS encrypts the S3 buckets.

Key Features and Benefits

Deploying the Guidance for Multi-Agent Orchestration using Amazon Bedrock AgentCore gives builders the following benefits:

Serverless, Isolated Agent Runtime

Benefit: You run production agents without managing servers, clusters, or autoscaling, and each user session is strongly isolated.
How: AgentCore Runtime hosts each agent as a containerized runtime and gives every user session its own dedicated microVM. Runtimes scale to thousands of concurrent sessions in seconds, and you pay for active runtime. Because every agent has its own runtime, you can update, scale, or replace one specialist without touching the others.

End-to-End Identity and Per-Hop Validation

Benefit: User identity is verified at every service boundary, so each sub-agent and tool validates the user's token before acting.
How:
  • JWT validated at every hop: AgentCore Runtime (supervisor and each sub-agent) and AgentCore Gateway each validate the Cognito-issued JWT independently.
  • Same token, whole chain: One JWT is passed through the entire call chain, so you can confirm the user's identity at any point by decoding it.
  • Programmatic data isolation:  customer_id  is passed in the payload by code, not inferred by the LLM. The model never decides which customer's data gets queried.
  • Edge protection: AWS WAF with AWS Managed Rules protects the CloudFront distribution, and KMS encrypts the S3 data buckets.

Managed Short-Term and Long-Term Memory

Benefit: Agents remember context within a conversation and learn customer facts and preferences across sessions, with no memory pipeline for you to build.
How: AgentCore Memory uses two tiers:
  • Short-term memory (STM) stores the current session's conversation history automatically.
  • Long-term memory (LTM) extracts facts and preferences in the background using semantic, summary, and user-preference strategies, and retrieves them later with semantic search.
Strands'  AgentCoreMemorySessionManager  connects this up. The Guidance uses one deliberate pattern: the supervisor retrieves LTM centrally and adds it to its context in  <user_context>  blocks. The Personalization and Troubleshooting agents keep their own STM and add to the shared memory resource, and the Order Management and Product Recommendation agents run without memory. You can change this, for example by letting sub-agents read LTM directly for more independent behavior.

Standardized Tool Access with MCP

Benefit: Existing APIs and Lambda functions become agent-ready tools without custom integration code.
How: AgentCore Gateway turns Lambda functions into MCP endpoints. The Guidance deploys eight of them across the specialists' Gateways (inventory, orders, customer database, browsing knowledge base, organic products, sponsored products, knowledge base query, and coordination). Any MCP-compatible agent can find and call these tools, and the Gateway enforces JWT authentication on every call.

Flexible Orchestration Patterns

Benefit: You start with a proven supervisor pattern and can move to more advanced coordination as needs change.
How: The Guidance uses the Strands "Agents as Tools" pattern, where the supervisor calls specialists like functions and combines their outputs. AgentCore also supports the Agent-to-Agent (A2A) protocol natively, which opens up other Strands multi-agent patterns such as Graph, Swarm, and Workflow.

Right-Sized Models for Cost and Latency

Benefit: You get strong reasoning where it matters and keep per-request costs down.
How: The supervisor uses Claude Sonnet 4.5 (US inference profile) for intent analysis and orchestration. The four sub-agents use Claude Haiku 4.5 (global cross-Region inference profile) for fast, inexpensive domain work. You can swap models per agent by changing configuration.

Built-In Observability

Benefit: You can see what every agent reasoned, which tools it called, and what memory it retrieved, all in one timeline.
How: AgentCore Observability sends OpenTelemetry traces to Amazon CloudWatch, including the CloudWatch GenAI Observability dashboard, which you enable with a one-time CloudWatch Transaction Search setup. The Guidance also includes a  show_agent_logs.py  script that filters out verbose telemetry and shows user messages, agent reasoning, tool calls with parameters, and accumulated long-term memories in order.

Simplified AWS Deployment

Benefit: You go from  git clone  to a working multi-agent application with one command.
How: The AWS CDK defines all seven stacks.  deploy-complete-system.sh  builds the agents, bootstraps CDK, deploys the stacks in the right order, configures and uploads the frontend, invalidates the CloudFront cache, sets up runtime authorization, and creates test users. An integration test suite validates the deployment.
The table below summarizes the main features and the components that provide them:
Feature Area
Specific Capability
How It's Enabled (AWS Service / Framework Feature)
Runtime
Serverless agent hosting with per-session microVM isolation
Amazon Bedrock AgentCore Runtime
Orchestration
Supervisor + specialist delegation
Strands "Agents as Tools" pattern
Orchestration
Graph, Swarm, Workflow patterns
AgentCore native A2A protocol + Strands
Security
User authentication
Amazon Cognito (JWT) + AgentCore Identity
Security
Per-hop token validation
AgentCore Runtime + AgentCore Gateway
Security
Programmatic data isolation
 customer_id  passed in payload, not by the LLM
Security
Edge and data protection
AWS WAF, Amazon CloudFront, AWS KMS
Memory
Session context (STM)
AgentCore Memory +  AgentCoreMemorySessionManager 
Memory
Cross-session facts and preferences (LTM)
AgentCore Memory semantic, summary, user-preference strategies
Tools
APIs and Lambda functions as MCP tools
AgentCore Gateway + AWS Lambda
Knowledge
RAG over profiles, FAQs, and guides
Amazon Bedrock Knowledge Bases + OpenSearch Serverless
Models
Reasoning + cost-efficient specialists
Claude Sonnet 4.5 (supervisor), Claude Haiku 4.5 (sub-agents)
User Experience
Real-time streaming responses
Server-Sent Events direct to AgentCore Runtime
Observability
Distributed tracing and metrics
AgentCore Observability (OpenTelemetry) + Amazon CloudWatch
Deployment
Infrastructure as code
AWS CDK (TypeScript) + one-command deploy script

Getting Started: Deploying Your Multi-Agent System

This section gives a high-level overview of deploying the Guidance.
Disclaimer: This walkthrough is based on the  GitHub repository  documentation available at the time of writing. Always check the official repository for current instructions. Deploying this solution incurs costs for the AWS resources used. As an AWS Guidance sample, support is best effort through the repository's GitHub Issues.

Prerequisites

Make sure you have the following before you start:
  • An AWS account with IAM permissions to create AgentCore resources (runtimes, memory, gateways), Bedrock Knowledge Bases, OpenSearch Serverless collections, Cognito user pools, S3, CloudFront, WAF, Lambda, ECR, KMS, IAM roles, Parameter Store, and CloudWatch Logs.
  • Amazon Bedrock model access for the models the agents use. By default, these are  amazon.titan-embed-text-v2:0  for Knowledge Base embeddings,  us.anthropic.claude-sonnet-4-5-20250929-v1:0  for the supervisor, and  global.anthropic.claude-haiku-4-5-20251001-v1:0  for the sub-agents. You can change the model for any agent in its configuration. If you use a global inference profile, enable cross-Region inference for it.
  • Enough service quotas for 5 AgentCore runtimes, 2 Knowledge Bases, 2 OpenSearch Serverless collections, and 1 Cognito user pool.
  • Node.js v22.x, AWS CDK CLI v2.220.0+, Python 3.13, AWS CLI v2, Docker, and Git.
  • A supported Region where AgentCore is available. At publication, that's us-east-1 or us-west-2.

Step 1: Clone the Repository

git clone https://github.com/aws-solutions-library-samples/guidance-for-multi-agent-orchestration-using-bedrock-agentcore-on-aws.git
cd guidance-for-multi-agent-orchestration-using-bedrock-agentcore-on-aws

Step 2: Deploy the Complete System

One script handles the infrastructure, agents, and frontend:
cd infrastructure
./deploy-complete-system.sh [PROFILE] [REGION]

# Examples
./deploy-complete-system.sh                        # AWS CLI defaults
./deploy-complete-system.sh my-profile             # specific profile
./deploy-complete-system.sh my-profile us-west-2   # specific profile + region
The script deploys these stacks in order:
Stack
What It Creates
 KnowledgeBaseStack 
OpenSearch Serverless collections and Bedrock Knowledge Bases
 CustomerSupportAssistantStack 
Supervisor agent runtime, Cognito, AgentCore Memory
 PersonalizationAgentStack 
Personalization agent runtime and Gateway
 OrderManagementAgentStack 
Order Management agent runtime and Gateway
 ProductRecommendationAgentStack 
Product Recommendation agent runtime and Gateway
 TroubleshootingAgentStack 
Troubleshooting agent runtime and Gateway
 FrontendStack-{region} 
S3, CloudFront, WAF (always deployed in us-east-1)
Tip: AgentCore Runtime runs on ARM64, so agent images are built for ARM64. On Apple Silicon or AWS Graviton, the first deployment takes about 20–25 minutes. On x86 machines, Docker emulation increases that to about 30–35 minutes. Later deployments take 10–15 minutes thanks to cached image layers.

Step 3: Verify and Access

When the script finishes, it prints a deployment summary (also saved to  infrastructure/deployment-outputs.json ) with:
  • The CloudFront website URL
  • Test user credentials and Cognito User Pool and Client IDs
  • AgentCore Runtime ARNs for all five agents
  • Knowledge Base IDs
  • Ready-to-run log monitoring and integration test commands
Open the website URL, sign in as a test user (for example,  carlos_salazar@example.com ), and try a multi-turn conversation:
User Says
What Happens Behind the Scenes
"I ordered a ProMax Laptop recently. Can you check my order status?"
Supervisor → Order Management Agent looks up the customer's order
"I returned it because it was overheating. What was wrong?"
Supervisor → Troubleshooting Agent queries the Knowledge Base
"What other laptops would you recommend for me?"
Supervisor → Personalization Agent (profile) → Product Recommendation Agent
"Is the UltraBook Air in stock?"
Supervisor → Order Management Agent checks inventory
Sign in as different test users (gold, silver, bronze, and platinum tiers, with different preferences) to see how responses change with each customer profile.

Step 4: Observe the Agents at Work

Watch the orchestration as it happens:
# Supervisor agent (last 30 minutes, default)
python3 scripts/show_agent_logs.py supervisor

# Personalization agent (last 60 minutes)
python3 scripts/show_agent_logs.py personalization --minutes 60

# Others: order-management, product-recommendation, troubleshooting
You'll see the supervisor's reasoning and delegation decisions, sub-agents calling MCP tools with their parameters, and, after a few conversations, a LONG-TERM MEMORY ACCUMULATED section listing what the system has learned about the user.
For full validation, run the integration tests:
python3 tests/integration/00_setup/test_setup.py   # first time only
python3 tests/integration/run_all_tests.py

Step 5: Customize and Extend (Optional)

  • Add specialized agents for billing, shipping, or returns.
  • Connect your own data by replacing the sample catalog, customer database, and knowledge base content.
  • Tune agent prompts in  agents/*/system_prompt.py  to match your brand voice.
  • Adjust memory strategies in  lambda/memory-manager/index.py .
  • Integrate your own identity provider in place of or alongside Cognito.
  • Rebrand the frontend in  frontend/src/ .
To remove resources when you're done, run  ./cleanup.sh [PROFILE]  from the  infrastructure  folder. You can delete everything or keep the Knowledge Base stack for a later deployment.

Why This Guidance Matters for AWS Builders

Here's why this Guidance is useful for teams building on AWS:
  • Faster path to production: Managed Runtime, Memory, Gateway, Identity, and Observability replace weeks of infrastructure work, so teams can focus on agent behavior and business logic.
  • Security by design: Per-session microVM isolation, JWT validation at every hop, and programmatic customer scoping are built in, and they're hard to build well from scratch.
  • Agents that remember: Managed short-term and long-term memory let agents use context from earlier conversations without a custom memory pipeline.
  • Reusable tools: MCP endpoints through AgentCore Gateway turn existing Lambda functions and APIs into tools that any compatible agent can use.
  • Room to grow: Framework- and model-agnostic runtimes, plus native A2A support, let you move from supervisor delegation to Graph, Swarm, or Workflow patterns as needs change.
  • Operational confidence: End-to-end OpenTelemetry tracing in CloudWatch shows how agents reason and collaborate, which simplifies debugging and tuning.
This Guidance removes the infrastructure barriers that keep multi-agent prototypes from reaching production, so teams can deliver agentic experiences to customers sooner.

Conclusion: Build Smarter with Managed Multi-Agent Orchestration

Multi-agent systems are a practical way to handle complex, multi-step customer interactions, but only when the underlying infrastructure is secure, scalable, and observable. The Guidance for Multi-Agent Orchestration using Amazon Bedrock AgentCore provides that foundation. It combines AgentCore's managed services with the Strands Agents SDK in a ready-to-deploy, CDK-based reference architecture that you can adapt to your own domain.
Clone the  repository , deploy it in 20 to 35 minutes, and start building multi-agent applications on AWS. To compare other orchestration approaches, such as the LangGraph implementation, see the full  Guidance for Multi-Agent Orchestration on AWS .
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article