Building AI Agent Teams in n8n with Bedrock AgentCore

In a guest post published on the n8n blog and authored by Sundar Raghavan, Agentic AI Foundations Lead at AWS, a method was presented for building multi-agent AI teams based on n8n and Amazon Bedrock AgentCore. The architecture allows different agents to share a unified per-customer memory, enabling one agent to continue a conversation using data collected by another agent within the same workflow, without setting up a vector database or deploying separate infrastructure for each agent.

The Challenge in Multi-Agent Support Conversations

In the support scenario described in the post, a triage agent routes a customer inquiry to an appropriate specialist (such as an integrations specialist). In such a scenario, the second specialist does not retain the context of the initial message sent by the customer forty seconds earlier.

Two common approaches address this challenge: passing the full conversation transcript to every agent—an approach constrained by the model's context window—or storing conversation history in a vector database, which requires operating database infrastructure and an embedding pipeline. The solution presented in the post offers a third alternative based on the managed memory capabilities of the Amazon Bedrock AgentCore harness, which has reached general availability (GA).

How Shared Memory Works in AgentCore Harness

Amazon Bedrock AgentCore is a platform for building, connecting, and optimizing agents across any framework or model. The AgentCore harness component provides managed scaffolding around the language model: the user defines the agent in configuration (including model, tools, skills, and instructions), and the harness manages the agent loop.

The setup relies on two core properties:

1. Managed Memory Scoped by Entity and Session: Memory is scoped by Actor ID and Session ID. When configuring an Actor ID that represents the customer rather than an individual agent, all agents can read from and write to the same memory store. This memory persists beyond a single execution of the n8n workflow.
2. Per-Invocation Tool Granting: Tools, skills, model, and instructions travel with each invocation rather than being permanently attached to a deployed agent. Consequently, a single harness resource serves four distinct specialist roles instead of deploying four separate resources.

The n8n Workflow Structure

The presented workflow consists of ten nodes in n8n:

• Receiving the Message: The When Chat Message Received node captures the customer inquiry.
• Setting Context: The Set Customer Context node converts the chat session into a customer identifier and broadcasts it as both the Actor ID and Session ID to all agents.
• Triage and Routing: The Triage Agent node reads the inquiry and returns a JSON classification, the Read Triage Decision node parses it, and the Route To Specialist node routes the query to one of three specialists:
  • An Analysis Specialist equipped with the AgentCore Code Interpreter tool for mathematical calculations in a sandbox environment.
  • An Architecture Specialist equipped with the AWS skills catalog for design guidance.
  • A Research Specialist utilizing built-in tools (Shell and file_operations) available in every harness session.
• Returning the Response: The Format Reply node formats the response, and the Post Answer To Slack node publishes it to a Slack channel, tagged with the specialist that generated it.

The division of responsibility between the systems is distinct: n8n handles triggers, routing decisions, and replies; AgentCore manages the agent loop and persistent memory across workflow runs, executing each session inside an isolated Firecracker microVM with no shared state or filesystem. Network traffic from n8n to AWS is outbound only and signed using the SigV4 protocol.

Prerequisites and IAM Identity Setup

Before running the template, the following components must be prepared:

• An n8n instance (self-hosted or n8n Cloud).
• The verified community node @aws/n8n-nodes-agentcore installed in n8n (the node is open-source under the MIT license, with AgentCore harness itself powered by Strands Agents from AWS).
• An AWS account with access to AgentCore harness in a supported AWS Region.
• A foundation model enabled in Amazon Bedrock (such as a Claude model), with model access configured on an opt-in basis per account and Region.
• Two separate AWS IAM identities: the Caller identity whose access keys are stored in n8n credentials, and the Execution Role under which the agent executes at runtime in AWS, requiring permissions for the model, Code Interpreter, skills catalog, and memory.
• Slack credentials for sending the reply (optional).

In terms of cost, there is no separate charge for the harness itself. Billing is based on usage of underlying AgentCore capabilities, with managed memory incurring standard AgentCore Memory rates for short-term events, stored long-term memory records, and retrieval requests.

Scenario Walkthrough: Billing Dispute and Architecture Guidance

During the test described in the post:

1. Data Calculation: The customer asked about exceeding a 50,000 daily API call limit and provided five numbers from their usage logs. The triage agent classified the request as analysis and routed it to the Analysis Specialist. The specialist executed Python code via the AgentCore Code Interpreter in a sandbox, calculated an average of 50,520 (an excess of 520 calls or 1%), and returned an execution-backed answer.
2. Follow-Up Without Repeating Data: The customer asked how to restructure the system to prevent overages, without repeating the usage figures. The triage agent routed the question to the Architecture Specialist, who utilized the AWS skills catalog. This specialist read the usage figures directly from shared customer memory under the same Actor ID, without requiring the customer to resubmit them and without either specialist needing direct awareness of the other.
3. General Information Query: A question regarding the daily limit reset time was routed to the Research Specialist, which operated using the built-in session tools.

Extension Options and Resource Cleanup

Users can extend the template by:

• Triggering via a Slack Trigger or Webhook for production environments.
• Integrating existing agents created via the CLI, AWS Console, CloudFormation, or Terraform by supplying their ARN to the node.
• Adding additional specialists with remote Model Context Protocol (MCP) servers, an AgentCore Gateway for governed access to your own APIs, or AgentCore Browser.

Upon completing testing, because the harness provisions a managed memory store in the AWS account, it is recommended to delete the created harness resource (e.g., support_team) via the AWS CLI using the aws bedrock-agentcore-control delete-harness command to avoid recurring charges.