Building Shared-Memory Multi-Agent Support Workflows in n8n Using Amazon Bedrock AgentCore

Building Shared-Memory Multi-Agent Support Workflows in n8n Using Amazon Bedrock AgentCore Amazon Bedrock AgentCore harness, now generally available, pairs with n8n to enable multi-agent support teams that share long-term customer context without requiring external vector databases or embedding pipelines. By leveraging single-harness provisioning and per-invocation configurations, workflows can route inquiries across specialist agents while maintaining a unified conversational history. Bedrock AgentCore harness runs agent loops in isolated Firecracker microVMs and allows a single harness to serve multiple specialist personas. Managed memory is scoped by Actor ID and Session ID, allowing different specialist agents to access the same historical context across workflow runs. Tools, skills, models, and prompts are assigned per invocation, keeping model input token costs low by avoiding unused tool definitions. Security is split between two IAM identities: the caller that invokes the harness and the execution role that grants agent permissions at runtime. Shared Memory and Per-Invocation Tools Traditional multi-agent setups risk losing context or overflowing token windows when handing conversations off between agents. AgentCore solves this by using managed memory scoped to an Actor ID, ensuring any specialist reading or writing under that identifier sees the same conversation history. Additionally, because tools and models travel with each invocation, a single provisioned harness can serve a triage agent and several specialists—such as an analysis agent with a code interpreter or an architecture specialist with AWS skills catalogs—without running separate agent infrastructure for each. Architecture, Security, and n8n Workflow Execution The n8n workflow manages triggers, routing logic, and output formatting, while AgentCore handles agent loops and persistent memory in the user's AWS account. Request traffic is strictly outbound from n8n using SigV4 signing. Authentication relies on two distinct IAM entities: the caller identity holding access keys inside n8n, and the execution role assuming permissions for models, memory, and sandboxed tools like the code interpreter at runtime. Demonstrated Support Routing and Lifecycle Management In a demonstrated customer scenario, an initial query requiring calculations is routed by the triage agent to an analysis specialist, which executes Python code in a sandbox. A subsequent architecture follow-up routes to a different specialist that immediately uses the previously calculated metrics without prompting the customer again. Because AgentCore reuses the harness based on the agent name cache key, the entire support team exists as a single harness resource that can be deleted via the AWS CLI to prevent recurring memory charges.

借助 Amazon Bedrock AgentCore 与 n8n 构建具备共享记忆的多智能体客服团队 通过结合 Amazon Bedrock AgentCore 与自动化平台 n8n，用户无需部署向量数据库或底层基础设施，即可搭建一个由分流 Agent 与多个专家 Agent 组成的智能客服团队，并实现跨 Agent 共享同一客户的历史上下文。 AgentCore harness 现已正式发布，支持在受管微虚拟机中运行 Agent 并提供跨会话托管记忆。 通过按客户划分的 Actor ID，不同专员 Agent 可在单一 harness 资源上读写同一份客户上下文。 工具与技能按单次调用授予，既降低模型输入 Token 成本，又避免部署多个独立 Agent 资源。 架构明确划分责任：n8n 负责触发与路由，AgentCore 在独立的 AWS 账户及环境中运行沙箱与存储。 多专员协作与统一记忆架构 传统客服多 Agent 场景中，任务交接常导致上下文丢失或迫使运维人员维护向量数据库。借助 Bedrock AgentCore 的托管记忆（Managed memory），系统以 Actor ID 与 Session ID 划分上下文范围。单一 harness 能够承载分流（Triage）与多个垂直专员（如代码解释、架构咨询、通用调研），让所有专员共享客户记忆，无需重复询问此前对话已提供的信息。 n8n 工作流与安全权限模型 工作流由 n8n 处理消息触发、分类判断及 Slack 回复推送，Agent 实际循环与记忆则由 AgentCore 在 AWS 的 Firecracker 微虚拟机中运行。权限体系分离为两个 IAM 主体：Caller 凭据用于在 n8n 中创建和调用 harness，Execution Role 则赋予 Agent 运行时访问模型、代码解释器及记忆所需的权限。工具按调用动态授予，大幅减少了未调用工具占用的输入 Token 开销。 生产演进与资源清理 测试完成后，由于系统基于 Agent Name 缓存并复用同一个 harness，测试全流程仅生成一个 harness 资源与相应的受管记忆。用户可通过 AWS CLI 随时删除该资源以避免产生额外费用。该开源节点同时支持生产级扩展，如无缝切换为 Slack/Webhook 触发、引入 Model Context Protocol (MCP) 或挂载私有 VPC 网络。

*This Verified Node Spotlight is a guest post written by Sundar Raghavan, Agentic AI Foundations Lead at AWS.* A customer messages your support bot that their nightly sync has been failing since they rotated their API keys. The triage agent reads it, decides this is a configuration problem, and hands off to your integrations specialist. The specialist asks which integration they mean. The customer already said. They said it in the message that started the conversation, forty seconds ago, in the same thread they are still looking at. From their side this is one conversation with one company. From the workflow's side it was two agents, and the second one started with nothing. You can pass the full transcript to every specialist, which works until the conversation outgrows the context window. You can put the history in a vector database, which works and now you operate a database and an embedding pipeline. This post takes a third route. [Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) is a platform to build, connect, and optimize agents at scale, with any framework or model. [AgentCore harness](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness.html), now generally available, provides the scaffolding around a model as a managed capability: you define an agent in configuration, including the model it uses, the tools it calls, the skills it has access to, and the instructions it follows, and AgentCore assembles and runs the loop for you. Two properties of that capability are what make a team of specialists practical. [AgentCore's Managed memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html) is scoped by actor and session, so an **Actor ID** that identifies the customer rather than any single agent gives every specialist the same history to read and write, and that history outlives an individual workflow execution. And because the tools, skills, model, and instructions travel with each invocation rather than being fixed on a deployed agent, one agent can serve all four specialists instead of provisioning four. In this post you will build that support team in the n8n editor: a triage agent that classifies each incoming question and routes it to one of three specialists, one holding the [AgentCore Code Interpreter](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/code-interpreter-tool.html), a capability of Amazon Bedrock AgentCore, for calculation, one holding the AWS skills catalog for architecture guidance, and one for everything else. The specialist answering the third question already knows what the first one learned, with no vector store to operate and no infrastructure to deploy. *Figure 1: Triage picks one specialist per question. All four agents run on the same harness and read and write one memory of the customer.* A customer asks a question in **When Chat Message Received**. **Set Customer Context** turns the chat session into a customer identifier, which every agent then sends as both its Actor ID and its Session ID. The **Triage Agent** reads the question and returns a category as JSON, which **Read Triage Decision** parses. **Route To Specialist** sends the question to the matching agent, which answers using the tools granted for that call. **Format Reply** unwraps the answer and **Post Answer To Slack** posts it, tagged with the specialist that produced it. Because every call carries the same Actor ID, every specialist reads and writes the same history, and the second question benefits from the first. A customer disputes their usage figures and the analysis specialist computes them. They follow up asking how to restructure, and a different specialist answers using those same figures without being told them again. Where all of this runs matters as much as what it does, because it determines what you have to operate. *Figure 2: Your n8n instance holds the workflow and the credentials. AgentCore runs the agent in your AWS account, under the execution role rather than the caller's keys.* The division of responsibility is straightforward. n8n handles the trigger, the routing decision, and the reply. AgentCore handles the agent loop and memory that outlives a workflow run, and runs every session in its own Firecracker microVM with no shared state and no shared filesystem. Ten nodes on the canvas, two credentials, and one harness resource rather than four. Traffic is outbound only, so nothing on your side needs to be exposed to the internet: n8n signs each request with SigV4 and calls AWS. And two IAM identities are doing different jobs, which the next section sets up. **The two IAM identities** AgentCore harness uses two separate IAM principals, and knowing which is which saves most first-run debugging. **The caller** is the identity whose access keys go into the n8n credential; it creates and invokes the harness. **The execution role** is what the agent runs as at runtime, so it needs the permissions for the model, the code interpreter, the skills catalog and memory. The [AgentCore harness security guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html) holds the canonical policies for both, and its sample execution role policy already covers everything this workflow uses. The node repository ships the trust policy at [\`docs/iam-trust-policy.json\`](https://github.com/aws/n8n-nodes-agentcore/blob/main/docs/iam-trust-policy.json), and the [README](https://github.com/aws/n8n-nodes-agentcore#which-permissions-each-feature-needs) maps each feature to the block it needs. An AccessDenied on the first run is almost always a missing action on the execution role rather than on the caller. Where you can, use temporary credentials from AWS IAM Identity Center or AWS STS. **A note on cost:** there is no separate charge for the harness itself. You pay for the underlying AgentCore capabilities you use, and managed memory incurs standard AgentCore Memory charges for short-term events, stored long-term memory records, and retrieval requests. This workflow creates one harness for all four agents rather than one each. Delete the agent when you are finished, and see [Amazon Bedrock AgentCore pricing](https://aws.amazon.com/bedrock/agentcore/pricing/). Import the free template to your n8n instance to follow along. The canvas will load with all ten nodes wired and configured. There is no harness to deploy, no container to build, no agent code to write, and no vector store to provision. Before running, check the canvas for warning markers on any node. n8n validates every node before it runs any of them, so a single unset credential stops the workflow. Open **Triage Agent**. Its **Harness ARN** field is blank, which tells the node to create the agent on the first run and reuse it afterwards. Under **Provisioning Options**, managed memory is enabled with the semantic, summarization, and user-preference strategies. *Figure 3: Only the Triage Agent provisions a harness. Memory is configured here because memory is a property of the harness rather than of an individual call.* Now open **Analysis Specialist**. Its Harness ARN is an expression: Expression `{{ $json.harnessArn }}` That is the ARN the Triage Agent returned. The specialist invokes the same harness instead of creating its own, and grants itself the AgentCore Code Interpreter for that single call. The Architecture Specialist does the same with the AWS skills catalog. Granting tools per call also keeps each specialist cheap, because tool definitions count toward model input tokens even when the agent never calls the tool. And every session arrives with two built-in tools regardless of what you configure, a shell and file\_operations, which is why the Research Specialist works with nothing configured at all. One detail to keep in mind: **Agent Name** in Set Customer Context is the cache key for the harness, and therefore for the team's memory. Changing it creates a new harness, and the accumulated customer history is no longer reachable from the workflow. Open the chat panel at the bottom of the canvas and send the kind of message a real customer sends, one with numbers buried in it: Your dashboard says I went over my 50,000 API calls a day plan but my own logs for the five busiest days are 41200, 38900, 52300, 61800, 58400. Am I actually over on average? The first run takes two to three minutes while AWS provisions the agent. Later runs answer in seconds. *Figure 4: Triage classified this as analysis because answering it means computing something, and routed it to the specialist holding the code interpreter.* Open the Analysis Specialist's output and expand toolUses. It contains the Python the agent wrote and executed: Python import statistics calls = \[41200, 38900, 52300, 61800, 58400\] print(statistics.mean(calls), statistics.pstdev(calls)) *Figure 5: The AgentCore Code Interpreter runs Python in a sandbox, so the number in the answer is the output of an execution rather than a prediction of one.* The mean is 50,520. The customer is over, by 520 calls a day out of 50,000, which is one percent. Here the answer is an execution, and the trace shows exactly what produced it. On a billing dispute that difference is the whole conversation. Stay in the same chat and send a follow-up that contains no numbers at all: That is closer than I thought. How should I restructure things so I stop going over? *Figure 6: A different specialist answers, and it uses the call volumes from the first question.* Triage classified this as architecture guidance and routed it to a different agent with different tools: the AWS skills catalog instead of the code interpreter. That agent was never sent the customer's call volumes, and it uses them anyway, because both calls went to the same harness with the same Actor ID. The first exchange was written into this customer's memory and the second call read it back. Neither specialist needed to know the other existed. This is the part a support team feels immediately. Without shared memory the customer would be asked to paste those five numbers again, in the same conversation, to a company that already has them. One scoping detail matters before this faces real customers: memory events are scoped by **Actor ID** plus **Session ID**, so a different Actor ID on the same harness gets an entirely separate memory. In this template the Actor ID comes from the chat session; in production you would set it from your own user, account or ticket ID. See [Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-memory.html) for the retention strategies and how retrieval is tuned. Now send something that is neither a calculation nor an architecture question: Also, does the daily limit reset at midnight UTC or in my local time? Open questions route to the Research Specialist, which works from the shell and file tools available in every harness session*.* Three messages from one customer, three specialists, one accumulating memory. From the customer's side it was a single conversation with a single company. *Figure 7: Each answer arrives in Slack tagged with the specialist that produced it.* The template is a starting point, and each direction below is configured the same way as the features above. **Trigger it from where your customers already are.** The chat panel needs no setup, which is why the template ships with it. A Slack Trigger or a Webhook is the natural production choice; both need an n8n instance reachable from the internet. **Use agents you have already built.** Replace a specialist's Harness ARN expression with the ARN of a harness you created through the AgentCore CLI, the console, CloudFormation, or Terraform. The node invokes it directly, and the configuration fields become per-invocation overrides. **Add a specialist.** One more branch on the Switch and one more agent node. Give it a remote [Model Context Protocol](https://modelcontextprotocol.io/) server, an [AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) for governed access to your own APIs, or the [AgentCore Browser](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-tool.html). For private VPC networking, OAuth-authenticated invocation, multi-provider model switching and the rest of what the node supports, see the [AWS Machine Learning Blog post](https://aws.amazon.com/blogs/machine-learning/run-production-ai-agents-in-n8n-with-amazon-bedrock-agentcore-harness/). The team is one harness resource in your AWS account, and it provisioned a managed memory store. Delete it when you are finished to avoid ongoing charges. List your harnesses: Bash aws bedrock-agentcore-control list-harnesses --region us-west-2 Then delete the one this template created, support\_team: aws bedrock-agentcore-control delete-harness \ --harness-id \<harness-id> --region us-west-2 Because the node reuses one harness per Agent Name, testing this workflow leaves a single resource behind regardless of how many questions you ask. You built a team of specialist agents that share one memory of each customer, without a vector store, a database, or any deployed infrastructure. Three ideas make it work: specialists do better work than generalists because each has the right tool for its job, memory scoped to the customer lets a team hand work between its members without asking the customer to repeat themselves, and tools granted per invocation mean a team of specialists does not have to become a fleet of separate resources to operate. Import the workflow to drop all nodes, wired and configured, to your n8n instance. For the rest of what the node supports, including private VPC networking and OAuth-authenticated invocation, see [Run production AI agents in n8n with Amazon Bedrock AgentCore harness](https://aws.amazon.com/blogs/machine-learning/run-production-ai-agents-in-n8n-with-amazon-bedrock-agentcore-harness/) on the AWS Machine Learning Blog. To learn more about the underlying capability, refer to the [AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/). The node is open source under MIT. AgentCore harness itself is powered by [Strands Agents](https://strandsagents.com/), the open source agent framework from AWS. Contributions and feedback are welcome on the [GitHub repository](https://github.com/aws/n8n-nodes-agentcore).