Multi-Agent E-Commerce Assistant

Introduction

30 Second Summary

When you contact customer support, your question often bounces between departments. One person handles shipping, another handles returns, and someone else handles product questions.

In this project, you will build a multi-agent e-commerce assistant using Amazon Bedrock. A supervisor agent receives customer questions and routes them to specialized collaborator agents that handle order tracking and store policy lookups.

What You'll Build

You'll type a question like "Where is my order ORD-1001?" into the Bedrock console and watch the Orchestrator route it to the right specialist, query a real database, and return shipment details in seconds.

By the end of this project, you'll have:

• An Orchestrator (supervisor) agent that classifies customer queries and delegates them to the right specialist automatically.
• An Order Status agent backed by a Lambda function that queries a DynamoDB orders table and returns tracking information.
• A Knowledge Base agent that answers e-commerce policy questions from documents stored in S3 using RAG (retrieval-augmented generation).
• A collaboration trace showing how the supervisor breaks down complex questions, invokes multiple agents, and synthesizes their responses.
• Secret Mission: Add a third Product Recommendations collaborator agent that suggests items based on a customer's order history.

Are there any prerequisites?

You need an AWS account with access to Amazon Bedrock. You should also be comfortable navigating the AWS Console and have basic experience with Lambda and IAM.

For Anthropic models, your account needs a one-time use case form submission (access is granted immediately after). Step 1 walks you through confirming this.

Before We Start

Before building, let's lock in what you're about to create and why it matters.

Set Up the Backend

Before any agent can answer customer questions, it needs data to query and tools to call. Without an orders table and policy documents in place, the agents you build in later steps would have nothing to look up.

In this step, you will create the three backend resources that power the multi-agent system: a DynamoDB table holding order records, an S3 bucket with store policy documents, and a Lambda function that queries orders on demand.

In this step, get ready to:

• Create a DynamoDB table with sample order data.
• Upload policy documents to an S3 bucket.
• Deploy and test a Lambda function that retrieves order details.

Create the DynamoDB orders table

Your Order Status agent needs a database to look up shipping info. DynamoDB is a serverless key-value database that your Lambda function will query using the order ID.

• Open the DynamoDB console by searching for DynamoDB in the AWS search bar and selecting it.
• Confirm you are in the us-east-1 region (check the region dropdown in the top-right corner).
• Click Create table.
• For Table name, enter EcommerceOrders.
• For Partition key, enter orderId with type String.
• Leave Table settings as Default settings (provisioned capacity with 5 RCU and 5 WCU, which stays within the free tier).
• Click Create table.

Wait until the table status shows Active (about 15-30 seconds).

Why DynamoDB?

DynamoDB is serverless. You pay nothing while the table sits idle within free tier limits (25 GB storage, 25 RCU, 25 WCU per month).

It also integrates natively with Lambda, so your function can query it with a single SDK call.

Now add three sample orders that the agent will look up during testing.

• Click your EcommerceOrders table name to open it.
• Click Explore table items.
• Click Create item.
• Switch to JSON view by toggling the view selector at the top.
• Paste the following JSON for the first order, then click Create item:

{
  "orderId": {"S": "ORD-1001"},
  "customerName": {"S": "Alice Johnson"},
  "product": {"S": "Wireless Headphones"},
  "status": {"S": "Shipped"},
  "estimatedDelivery": {"S": "2026-07-28"},
  "trackingNumber": {"S": "TRK-9876543"}
}

• Click Create item again and paste the second order:

{
  "orderId": {"S": "ORD-1002"},
  "customerName": {"S": "Bob Smith"},
  "product": {"S": "USB-C Hub"},
  "status": {"S": "Processing"},
  "estimatedDelivery": {"S": "2026-07-31"},
  "trackingNumber": {"S": ""}
}

• Click Create item once more and paste the third order:

{
  "orderId": {"S": "ORD-1003"},
  "customerName": {"S": "Carol Davis"},
  "product": {"S": "Laptop Stand"},
  "status": {"S": "Delivered"},
  "estimatedDelivery": {"S": "2026-07-20"},
  "trackingNumber": {"S": "TRK-1234567"}
}

You should now see all three items listed in the table's item explorer.

Don't see your items?

Make sure you toggled to JSON view before pasting. If you used the form view instead, DynamoDB may have interpreted the fields incorrectly.

Also confirm the orderId key matches your partition key name exactly (case-sensitive).

Help me troubleshoot my DynamoDB items

Create the S3 bucket and upload policy documents

The Knowledge Base agent needs source documents to answer policy questions. You will store a return policy and a shipping policy in S3 so the knowledge base can ingest them later.

• Open the S3 console by searching for S3 in the AWS search bar and selecting it.
• Click Create bucket.
• For Bucket name, enter ecommerce-policies- followed by your AWS account ID (e.g. ecommerce-policies-123456789012).
• Confirm AWS Region is set to US East (N. Virginia) us-east-1.
• Leave all other settings as defaults and click Create bucket.

Why include your account ID in the bucket name?

S3 bucket names must be globally unique across all AWS accounts. Appending your account ID guarantees no one else has already taken the name.

Now create two policy text files on your local machine and upload them.

• On your computer, create a file named return-policy.txt with the following content:

Return Policy

We offer a 30-day return window from the date of delivery.

Condition Requirements:
- Items must be unused and in original packaging
- All tags and labels must be attached
- Items must not show signs of wear or damage

Refund Timeline:
- Refunds are processed within 5-7 business days after we receive the returned item
- Refunds are issued to the original payment method

Non-Returnable Items:
- Gift cards
- Downloadable software
- Personal care items
- Items marked as final sale

• Create a second file named shipping-policy.txt with the following content:

Shipping Policy

Standard Shipping:
- Delivery time: 5-7 business days
- Cost: $4.99 for orders under $50

Express Shipping:
- Delivery time: 2-3 business days
- Cost: $12.99

Free Shipping:
- Available on all orders over $50
- Uses standard shipping delivery times (5-7 business days)

International Shipping:
- Available to select countries
- Delivery time: 10-14 business days
- Customs fees may apply and are the responsibility of the customer

• Back in the S3 console, click your ecommerce-policies- bucket name to open it.
• Click Upload.
• Click Add files and select both return-policy.txt and shipping-policy.txt.
• Click Upload.

You should see a green success banner and both files listed in the bucket.

Upload failed?

Check that both files have the .txt extension and are not empty. Also confirm the bucket was created in us-east-1. The knowledge base you create later must be in the same region as the bucket.

Help me fix my S3 upload

Create the Lambda function for order lookup

The Order Status agent will call a Lambda function whenever it needs to fetch order data. This function receives an order ID from the Bedrock agent, queries DynamoDB, and returns the result in the format Bedrock expects.

• Open the Lambda console by searching for Lambda in the AWS search bar and selecting it.
• Click Create function.
• Select Author from scratch.
• For Function name, enter EcommerceOrderLookup.
• For Runtime, select Python 3.12.
• Leave Architecture as x86_64.
• Under Permissions, expand Change default execution role and select Create a new role with basic Lambda permissions.
• Click Create function.

Lambda creates the function and opens the code editor.

• In the Code tab, select all existing code in lambda_function.py and replace it with the following:

import json
import boto3

# Connect to the DynamoDB orders table
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('EcommerceOrders')

def lambda_handler(event, context):
    # Extract orderId from the Bedrock agent parameters
    parameters = event.get('parameters', [])
    order_id = None

    for param in parameters:
        if param['name'] == 'orderId':
            order_id = param['value']
            break

What does this code do?

When Bedrock invokes this Lambda via an action group, it sends an event containing a parameters list. Each parameter has a name and a value.

This block loops through the list to find the orderId the customer asked about.

• Add the DynamoDB query and error handling below the code you just pasted:

    # Query DynamoDB for the order
    if order_id:
        try:
            response = table.get_item(Key={'orderId': order_id})
            if 'Item' in response:
                order = response['Item']
                result = json.dumps({
                    'orderId': order['orderId'],
                    'customerName': order['customerName'],
                    'product': order['product'],
                    'status': order['status'],
                    'estimatedDelivery': order['estimatedDelivery'],
                    'trackingNumber': order['trackingNumber']
                })
            else:
                result = json.dumps({'error': f'No order found with ID {order_id}'})
        except Exception as e:
            result = json.dumps({'error': str(e)})
    else:
        result = json.dumps({'error': 'orderId parameter is required'})

What does this code do?

The function calls get_item on DynamoDB using the extracted order ID. If the item exists, it extracts all order fields into a JSON string.

If no item matches or an error occurs, the function returns a descriptive error message instead of crashing.

• Add the return statement below the code you just pasted:

    # Return response in Bedrock agent function details format
    return {
        'messageVersion': '1.0',
        'response': {
            'actionGroup': event.get('actionGroup', ''),
            'function': event.get('function', ''),
            'functionResponse': {
                'responseBody': {
                    'TEXT': {
                        'body': result
                    }
                }
            }
        }
    }

Why this specific response format?

Bedrock expects a precise response structure from function-based action groups. The functionResponse wraps your result in a TEXT body so the agent can read it and formulate a natural language answer for the customer.

• Click Deploy to save and deploy the function.

You should see a green banner confirming the function was updated successfully.

✔️ Awesome, I've got everything!

Great. Make sure you clicked Deploy and saw the success banner before continuing.

ⓧ I'd like to double check the full code

Your lambda_function.py should contain all three chunks you pasted above, in this order:

• Chunk 1: import json and import boto3 at the top, followed by the DynamoDB table connection and the lambda_handler function definition with the parameter extraction loop.
• Chunk 2: The if order_id: block containing the get_item call, result formatting, and error handling.
• Chunk 3: The return statement with the messageVersion, response, and functionResponse structure.

Scroll up and confirm each chunk is present in order. All indentation inside lambda_handler should be 4 spaces deep.

Next, give the Lambda function permission to read from DynamoDB.

• Click the Configuration tab.
• Click Permissions in the left sidebar.
• Under Execution role, click the role name link (it opens the IAM console in a new tab).
• In the IAM console, click Add permissions, then Attach policies.
• Search for AmazonDynamoDBReadOnlyAccess.
• Select the checkbox next to it and click Add permissions.

You should see AmazonDynamoDBReadOnlyAccess listed under the role's permissions policies.

What is this policy?

AmazonDynamoDBReadOnlyAccess is an AWS managed policy that grants read-only access to all DynamoDB tables in your account.

Your Lambda function only needs to read order data, so read-only access follows the principle of least privilege.

Now add a resource-based policy so that Bedrock can invoke this Lambda function.

• Switch back to the Lambda console tab.
• In the Configuration tab, click Permissions in the left sidebar.
• Scroll down to Resource-based policy statements.
• Click Add permissions.
• Select AWS service.
• For Service, select Other.
• For Statement ID, enter AllowBedrockInvocation.
• For Principal, enter bedrock.amazonaws.com.

• For Source ARN, enter arn:aws:bedrock:us-east-1: followed by your AWS account ID, then :agent/* (e.g. arn:aws:bedrock:us-east-1:123456789012:agent/*).
• For Action, select lambda:InvokeFunction.
• Click Save.

What does this resource-based policy do?

This policy allows the Amazon Bedrock service (bedrock.amazonaws.com) to call your Lambda function.

The Source ARN wildcard (agent/*) means any Bedrock agent in your account can invoke it.

Finally, test the function to confirm it can read from DynamoDB.

• Click the Test tab in the Lambda console.
• For Event name, enter TestOrder1001.
• Replace the default event JSON with the following test payload:

{
  "messageVersion": "1.0",
  "agent": {
    "name": "test-agent",
    "id": "TEST123",
    "alias": "TSTALIASID",
    "version": "DRAFT"
  },
  "inputText": "What is the status of order ORD-1001?",
  "sessionId": "test-session-123",
  "actionGroup": "OrderLookupActions",
  "function": "getOrderStatus",
  "parameters": [
    {
      "name": "orderId",
      "type": "string",
      "value": "ORD-1001"
    }
  ],
  "sessionAttributes": {},
  "promptSessionAttributes": {}
}

What is this test event?

This mimics the exact event structure that Bedrock sends when a function-based action group is invoked. The key field is parameters which contains the orderId value ORD-1001 that your function will query in DynamoDB.

Before you click Test, what do you expect to see in the response? Think about what the function does with an order ID that exists in the table.

• Click Test.

You should see a green execution result containing order details for Alice Johnson, including status "Shipped", estimated delivery "2026-07-28", and tracking number "TRK-9876543".

Seeing an AccessDeniedException?

This means the Lambda execution role does not have permission to read DynamoDB. Go back to the IAM tab and confirm you attached AmazonDynamoDBReadOnlyAccess to the correct role (the one shown under Execution role in the Lambda Configuration tab).

Help me fix my Lambda permissions

Your backend is fully wired. DynamoDB holds the order data, S3 holds the policy documents, and Lambda can query orders on demand.

Next up, you will create your first Bedrock agent and connect it to this Lambda function so it can answer order status questions in natural language.

Build the Order Status Agent

Your backend infrastructure is live. The Lambda function queries DynamoDB and returns order details on command. Now it's time to put an AI brain in front of that function.

In this step, you'll create an Amazon Bedrock agent that understands natural language order questions, calls your Lambda function with the right parameters, and returns a conversational response. Building and testing it in isolation proves the action group pattern works before you wire it into the multi-agent system.

In this step, get ready to:

• Create a Bedrock agent with order-specialist instructions.
• Attach an action group that connects the agent to your Lambda function.
• Test the agent with real order queries and create an alias for multi-agent use.

Create the Order Status agent

A Bedrock agent needs three things: a foundation model for reasoning, instructions that define its role, and a service role for permissions. The console handles the service role automatically.

• In the AWS Console, type Bedrock in the top search bar and open the Amazon Bedrock service.
• In the left navigation panel, expand Builder tools and select Agents.
• Click Create Agent.
• For Name, enter order-status-agent.
• Click Create. The Agent builder opens.

You're now in the Agent builder where you configure the model and instructions.

• In the Agent details section, for Agent resource role, leave the default Create and use a new service role.
• For Select model, choose Anthropic as the provider and select Claude Sonnet 4.6 (anthropic.claude-sonnet-4-6).
• In the Instructions for the Agent field, paste the following text:

You are an e-commerce order status specialist. You help customers check the status of their orders by looking up order information using the order ID. Always provide the order status, estimated delivery date, and tracking number if available. If no order is found, let the customer know politely.

• Click Save at the top of the Agent builder.

What do these instructions do?

The instructions define the agent's persona and behaviour. When a user asks a question, the model reads these instructions to decide how to respond and which tools to call.

Telling the agent to "always provide the order status, estimated delivery date, and tracking number" ensures it extracts all relevant fields from the Lambda response rather than giving a vague summary.

You should see a green success banner confirming the agent was saved.

Don't see the model listed?

If Claude Sonnet 4.6 doesn't appear, make sure you're in the us-east-1 region. Also confirm you've submitted the Anthropic use case form (one-time per account). Access is granted immediately after submission.

Help me enable Anthropic model access

Add the action group

The agent can reason about orders, but it has no way to look up real data yet. An action group connects the agent to your Lambda function so it can retrieve live order information from DynamoDB.

• In the Agent builder, select the Action groups tab.
• Click Add.
• For Enter Action group name, enter OrderLookupActions.
• In Action group type, select Define with function details.
• In Action group invocation, choose Select an existing Lambda function.
• From the dropdown, select EcommerceOrderLookup.

Now you need to define what function the agent can call and what parameters it should collect from the user.

• Under the function definition section, click Add function.
• For the function name, enter getOrderStatus.
• For the description, enter Retrieves order status and tracking information for a given order ID.
• Add a parameter with name orderId, type String, and description The order ID to look up, e.g. ORD-1001.
• Check the Required checkbox for the orderId parameter.
• Click Create to save the action group.

Why Define with function details?

Bedrock Agents offers two ways to describe an action group: an OpenAPI schema or function details. Function details is simpler because you list parameters directly in the console without writing YAML.

The agent uses the function description and parameter descriptions to decide when to call the function and what information to collect from the user first.

• Back in the Agent builder, click Save.
• Click Prepare to compile the agent with your new action group.

You should see a message confirming the agent was prepared successfully.

Seeing a permissions error on Prepare?

If preparation fails with a permissions error, the agent's service role may not have lambda:InvokeFunction permission for your function. Confirm that the resource-based policy on the EcommerceOrderLookup Lambda allows Bedrock to invoke it (this was set up in Step 1).

Help me fix Lambda invocation permissions

Test the agent and create an alias

The agent is prepared. Before wiring it into a multi-agent system, you need to prove it can handle real queries on its own.

Before you type the test query below, what do you think the agent will do? Will it respond with order details directly, or will it need to call your Lambda function first?

• In the test panel on the right side of the Agent builder, type the following message and press Enter:

What is the status of order ORD-1001?

The agent calls your Lambda function and responds with the order details: "Shipped" status, estimated delivery of 2026-07-28, and tracking number TRK-9876543.

What just happened?

The agent read the user's question, recognized it needed order data, called the getOrderStatus function with orderId = ORD-1001, received the JSON from your Lambda, and composed a natural language response.

That entire chain happened automatically based on the instructions and function description you provided.

• Test with a second query to confirm it handles different order states. Type:

Where is my order ORD-1003?

The agent responds with details for the delivered order, including tracking number TRK-1234567.

Now you need to create an alias so this agent can be referenced by the orchestrator later.

• Navigate back to the agent's main page by clicking Save and exit in the Agent builder.
• In the Aliases section, click Create.
• For Alias name, enter v1.
• Under Associate a version, select Create a new version and associate it to this alias.
• Click Create alias.

You should see the v1 alias appear in the Aliases table with a status of Created.

Why create an alias?

An alias is a stable pointer to a specific version of your agent. Multi-agent collaboration requires each collaborator to have an alias. The orchestrator will reference this v1 alias when routing order questions to this agent.

Agent not responding with order details?

If the agent replies with generic text instead of calling Lambda, make sure you clicked Prepare after adding the action group. Unprepared changes are not active in the test panel.

Also verify that the orderId parameter is marked as Required in your function definition. Without this, the agent may not pass it to Lambda.

Help me debug my agent's Lambda connection

Your first collaborator agent is built, tested, and aliased. Next up, you'll create the Knowledge Base agent that answers policy questions from your uploaded documents.

Build the Knowledge Base Agent

Your Order Status agent can look up shipment details, but it has no idea what your store's return policy says or how long shipping takes.

The system needs a second specialist to demonstrate routing. A Knowledge Base agent shows RAG (retrieval-augmented generation), which is a different capability from action group tool calls. Instead of running code, this agent retrieves answers directly from your uploaded policy documents.

In this step, get ready to:

• Create a Knowledge Base that indexes your S3 policy documents into a vector store.
• Create a Knowledge Base agent that answers policy questions using RAG.
• Test the agent to confirm it retrieves specific policy details from your documents.

Create the Knowledge Base

A Knowledge Base converts your documents into vector embeddings so an LLM can search them semantically. You uploaded policy documents to S3 in Step 1. Now you will point a Knowledge Base at that bucket.

• In the Bedrock console, choose Knowledge bases in the left navigation pane.
• Click Create, then select Knowledge Base with vector store.
• Change the name to ecommerce-policies-kb.
• Under IAM permissions, leave Create and use a new service role selected.
• For the data source, choose Amazon S3 and click Next.
• Enter the S3 URI of your ecommerce-policies- bucket (click Browse S3 to find it quickly).
• Click Next to proceed to the embeddings model step. Leave the default managed embedding model selected (no configuration needed).
• In the Vector database section, select Quick create a new vector store.
• Click Next, review your settings, then click Create knowledge base.

Wait 2-5 minutes for the Knowledge Base and vector store to finish creating.

What is happening behind the scenes?

Bedrock creates an IAM service role that grants the Knowledge Base permission to read from your S3 bucket. It also provisions a managed vector store where your document embeddings will live.

The embedding model converts each chunk of text into a numerical vector. When you later ask a question, Bedrock converts your query into a vector too, then finds the most similar document chunks to include in the LLM's context.

• Once the Knowledge Base status shows Available, select your data source in the Data source section and click Sync.

When the sync completes, a green success banner appears. Your two policy documents are now ingested as vector embeddings.

Sync failed or showing warnings?

Check that your S3 bucket is in us-east-1 (the same region as the Knowledge Base). Cross-region buckets are not supported.

Verify that both return-policy.txt and shipping-policy.txt are in the bucket root, not nested inside a subfolder.

help me troubleshoot why my Knowledge Base sync failed

Create the Knowledge Base agent

The Knowledge Base holds your documents, but it cannot answer questions on its own. You need an agent that knows how to query the Knowledge Base and turn the retrieved chunks into a natural-language response.

• In the Bedrock console, choose Agents under Builder tools in the left navigation pane.
• Click Create Agent.
• Set the agent name to knowledge-base-agent.
• For the model, select Claude Sonnet 4.6 (anthropic.claude-sonnet-4-6).
• In the Instructions for the Agent field, paste the following:

You are an e-commerce policy specialist. You answer customer questions about store policies including returns, shipping, refunds, and general FAQ. Always cite the specific policy details. If you cannot find the answer in your knowledge base, say so clearly.

• Click Save to save the agent.
• Scroll down to the Knowledge bases section and click Add.
• Select ecommerce-policies-kb from the dropdown.
• In the instructions field for the knowledge base association, enter: Use this knowledge base to answer all questions about store policies including returns, shipping, refunds, and FAQ.
• Click Add. A success banner confirms the association.
• Click Prepare at the top of the page to apply your changes.

Why associate a Knowledge Base with an agent?

The Knowledge Base holds vectors, but it has no reasoning ability. The agent provides the LLM layer that interprets user questions, decides when to query the Knowledge Base, and synthesizes the retrieved chunks into a coherent answer.

The association instructions tell the agent when to use this particular Knowledge Base. Later, the Orchestrator will use similar instructions to decide which collaborator to call.

Test and create alias

Before wiring this agent into the multi-agent system, confirm it retrieves real policy details from your documents.

Before you type the test query, think about what you expect to see. Will the agent answer from memory, or will it pull specific details from your uploaded documents?

• In the test panel on the right side of the agent builder, type:

What is your return policy?

The agent responds with specific details from your return-policy.txt document: the 30-day return window and the 5-7 business day refund timeline.

• Test with a second query to confirm the shipping policy is also accessible:

How long does standard shipping take?

The agent should respond with details about standard shipping (5-7 days) from your shipping-policy.txt document.

Agent not returning policy details?

Make sure you clicked Prepare after adding the Knowledge Base. Without preparing, the agent uses a stale draft that has no Knowledge Base association.

Confirm the data source sync completed with a green banner. If the sync is still in progress, the vectors are not yet queryable.

help me debug why my Bedrock agent is not retrieving data from its associated knowledge base

• Now create an alias so this agent can be used as a collaborator. In the agent overview, click Create Alias.
• Set the alias name to v1 and click Create.

Why do agents need aliases?

Multi-agent collaboration requires each collaborator to be referenced by an alias (a stable pointer to a specific version). The Orchestrator will reference this v1 alias when routing policy questions to the knowledge-base-agent.

You now have two working specialist agents: one that queries a database and one that retrieves answers from documents. Next up, you will wire them both into an Orchestrator that routes customer questions to the right specialist automatically.

Wire Up the Orchestrator Agent

You now have two specialist agents that each excel in their own domain. The Order Status agent queries DynamoDB for shipment details. The Knowledge Base agent retrieves policy answers from your uploaded documents.

The problem is that a customer asking a question has to know which agent to talk to. In a real support system, a single entry point should handle any question and route it to the right specialist automatically. That is the job of the Orchestrator.

In this step, get ready to:

• Create a supervisor Orchestrator agent with multi-agent collaboration enabled.
• Add both collaborator agents and configure routing instructions.
• Test single-domain and multi-domain queries to observe intelligent routing.

Create the Orchestrator agent with multi-agent collaboration

The Orchestrator is a supervisor agent. It receives every customer question, decides which specialist should handle it, and synthesizes the results into a single response.

• In the Amazon Bedrock console, select Agents in the left navigation pane.
• Choose Create Agent.
• Change the Name to ecommerce-orchestrator.
• Turn on Enable Multi-agent collaboration before choosing Create.
• Choose Create. You will be taken to the Agent builder.

Why enable multi-agent collaboration at creation time?

This toggle designates the agent as a supervisor. Without it, the agent cannot associate collaborator agents. You must enable it before saving the agent for the first time.

• In the Agent builder, select the model Claude Sonnet 4.6 (anthropic.claude-sonnet-4-6).
• In the Instructions field, paste the following text:

You are the main e-commerce customer support orchestrator. You receive customer questions and route them to the appropriate specialist agent. For order status and tracking questions, delegate to the order status specialist. For policy questions about returns, shipping, and refunds, delegate to the policy specialist. For questions that span multiple domains, consult both specialists and combine their responses into a single helpful answer.

What do these instructions do?

The supervisor uses these instructions to decide which collaborator handles a given query. Clear, non-overlapping routing rules help the model classify questions accurately.

• Choose Save at the top of the Agent builder.

Saving the agent first is required before you can associate collaborators. You should now see the agent's detail page with a status indicator.

Don't see the model in the dropdown?

Anthropic models require a one-time use case form submission per AWS account. If Claude Sonnet 4.6 is not listed, navigate to Model access in the Bedrock console and complete the Anthropic access request. Access is granted immediately after submission.

Help me enable Anthropic model access in my Bedrock console.

Configure collaboration and add collaborators

With the agent saved, you can now set the collaboration mode and wire in your two specialist agents as collaborators.

• In the Agent builder, scroll down to the Multi-agent collaboration section and choose Edit.
• In the Collaboration configuration section, select Supervisor.

Why Supervisor instead of Supervisor with routing?

Supervisor mode makes the orchestrator analyze every request, break it down, and coordinate responses from collaborators. With routing mode, simple requests bypass the supervisor and go directly to a sub-agent.

Supervisor mode is better for learning because you always see the full orchestration trace. You can observe how the model reasons about which collaborator to invoke and how it synthesizes the combined answer.

Now add the first collaborator.

• Expand the Agent collaborator section.
• For Collaborator agent, select order-status-agent from the dropdown.
• For Agent alias, select v1.
• For Collaborator name, enter order-status-specialist.
• In Collaboration instructions, enter:

Use this agent when the customer asks about order status, tracking, delivery estimates, or shipment information. The customer will provide an order ID.

• Choose Add collaborator.

Now add the second collaborator.

• For Collaborator agent, select knowledge-base-agent from the dropdown.
• For Agent alias, select v1.
• For Collaborator name, enter policy-specialist.
• In Collaboration instructions, enter:

Use this agent when the customer asks about store policies including returns, shipping times, refunds, or general FAQ questions.

• Choose Add collaborator.
• Choose Save.
• Choose Prepare to compile the agent with its new collaborator configuration.

After preparation completes, the agent status updates. You now have a supervisor with two collaborators wired in.

Cannot add collaborators?

Make sure you saved the Orchestrator agent before attempting to add collaborators. The supervisor agent must be saved first. Also confirm that both collaborator agents have a v1 alias created. Agents without an alias cannot be associated as collaborators.

Help me troubleshoot adding collaborator agents to my supervisor.

Test multi-agent collaboration

Time to see the Orchestrator in action. You will send three different queries to observe how it routes to the correct specialist.

• In the Bedrock console, open the ecommerce-orchestrator agent.
• The Test window appears in the right pane.
• In the chat input, type the following and choose Run:

What is the status of order ORD-1001?

• Select Show trace to expand the trace panel.

In the trace, you should see the supervisor reasoning about the query, then delegating to order-status-specialist. The response includes details like "Shipped" status and tracking number TRK-9876543.

• Start a new conversation by selecting the refresh icon in the Test window.
• Type the following query and choose Run:

What is your return policy?

Check the trace again. This time the supervisor routes to policy-specialist. The response should mention the 30-day return window and 5-7 business day refund timeline from your uploaded policy document.

Now for the real test. Before you run the next query, think about what you expect to happen. Will the Orchestrator call one agent or both?

• Start a new conversation by selecting the refresh icon.
• Type the following multi-domain query and choose Run:

What is the status of order ORD-1001 and can I return it if I don't like it?

Expand Show trace. The supervisor invokes BOTH collaborators. You can see the full orchestration flow: the supervisor's reasoning, delegation decisions to each specialist, the individual collaborator responses, and the final synthesized answer combining order status with return policy information.

What is the collaboration trace showing?

The trace reveals the supervisor's step-by-step reasoning process. First it identifies that the query spans two domains. Then it invokes order-status-specialist for shipment details and policy-specialist for return policy. Finally it synthesizes both responses into one coherent answer.

This is the power of the supervisor pattern. The customer asks one question and gets a complete answer without needing to know which specialist handles which domain.

Agent not routing to collaborators?

If the Orchestrator answers from its own knowledge instead of delegating, verify that you chose Prepare after adding both collaborators. Unprepared changes do not take effect. Also confirm the collaboration instructions clearly distinguish when each collaborator should be used.

Help me debug why my Orchestrator is not delegating to collaborator agents.

Your multi-agent system is fully operational. A single entry point now handles order tracking, policy questions, and complex queries that span both domains. In the Secret Mission, you will stretch this architecture further by adding a third specialist agent.

Secret mission

Add a Product Recommendations Agent

Your two-agent system handles orders and policies. But real customer support systems have more specialists. Can you add a third collaborator that recommends products based on a customer's purchase history, and teach the Orchestrator to coordinate all three?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Most resources in this project are serverless and only incur charges when actively used. The Bedrock Knowledge Base vector store may incur small charges over time, and agent invocations are billed per model token usage.

Cost warning

The Bedrock Knowledge Base vector store and agent invocations are charged based on usage.

If you are not planning to use these resources again, delete them to avoid any unexpected charges.

Resources you used:

• DynamoDB table EcommerceOrders (free tier, no ongoing cost).
• S3 bucket ecommerce-policies-{your-account-id} with policy documents (negligible storage cost).
• Lambda functions: EcommerceOrderLookup and EcommerceRecommendations (free tier: 1M requests/month).
• Bedrock Knowledge Base ecommerce-policies-kb with managed vector store (charged per sync and query).
• Bedrock Agents: ecommerce-orchestrator, order-status-agent, knowledge-base-agent, and recommendations-agent (charged per invocation via model token usage).

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with your multi-agent system.

• The DynamoDB table and Lambda functions are within free tier limits and cost nothing at rest.
• Bedrock Agents only incur charges when you invoke them (test or API calls).
• The Knowledge Base vector store may incur small charges if it remains synced. Consider un-syncing the data source if you are not actively querying it.

Pause - I'll come back to this later

All resources in this project are serverless. They only cost money when you use them.

• No action is required to pause. Simply stop testing your agents in the Bedrock console.
• Your DynamoDB table, Lambda functions, S3 bucket, Knowledge Base, and agents remain available whenever you return.

Delete - I don't want to use this again

Remove all project resources. Follow this order to avoid dependency errors.

• Delete the Orchestrator agent first. In the Bedrock console, select Builder tools in the left navigation, then Agents. Select ecommerce-orchestrator, then choose Delete. Confirm the deletion.
• Delete the collaborator agents next. Repeat the same process for order-status-agent, knowledge-base-agent, and recommendations-agent.
• Delete the Knowledge Base. In the Bedrock console, select Knowledge Bases in the left navigation. Select ecommerce-policies-kb and choose Delete. This also removes the managed vector store.
• Delete the Lambda functions. In the Lambda console, select Functions. Select EcommerceOrderLookup, choose Actions, then Delete. Repeat for EcommerceRecommendations.
• Delete the DynamoDB table. In the DynamoDB console, select Tables. Select EcommerceOrders and choose Delete. Confirm by typing the table name when prompted.
• Empty and delete the S3 bucket. In the S3 console, select your ecommerce-policies-{your-account-id} bucket. Choose Empty and confirm. Then choose Delete and confirm by typing the bucket name.

That's a Wrap!

That's a Wrap!

Nice work! You just built a multi-agent collaboration system on Amazon Bedrock where a supervisor agent intelligently routes e-commerce queries to specialized collaborators and synthesizes their responses into a single coherent answer.

You've learned how to:

• Built a Knowledge Base agent using RAG to answer e-commerce policy questions from documents stored in S3.
• Created an Order Status agent with a Lambda action group that queries DynamoDB for real order data.
• Configured a supervisor Orchestrator that classifies queries, delegates to the right specialist, and combines multi-domain responses into a single answer.
• Secret Mission: Added a third Product Recommendations agent, proving the system scales with additional specialists and the supervisor adapts its routing automatically.

Ready to quiz yourself?