内容来源：https://blog.n8n.io/node-spotlight-amazon-bedrock-agentcore/

内容总结：

AWS推出AgentCore托管平台，助力企业构建共享记忆的多智能体客服团队

亚马逊云科技（AWS）近日发布了一篇技术文章，详细介绍了一项名为Amazon Bedrock AgentCore的新能力。该平台旨在解决企业在部署AI智能体时面临的一个关键难题：当多个专业智能体协作处理客户问题时，如何实现客户信息的无缝共享，避免客户重复陈述已提供的信息。

多智能体协作的记忆断层问题

文章以一个典型的客服场景开篇：客户向支持机器人反映其夜间同步功能在轮换API密钥后持续失败。分流智能体判断这是配置问题，将任务转交给集成专家，但后者却反问客户指的是哪个集成——尽管客户在四十秒前的同一对话中已经说明。从客户角度看，这是一次与同一家公司的单一对话，但从工作流角度看，却是两个互不相通的智能体各自为战。

传统解决方案要么将完整对话记录传递给每个专家（当对话超出上下文窗口时失效），要么引入向量数据库进行历史存储（增加了运维复杂度）。AWS此次发布的AgentCore harness提供了第三条路径。

AgentCore核心特性：托管记忆与按需工具配置

AgentCore是AWS推出的智能体构建平台，支持任意框架和模型，能够大规模构建、连接和优化智能体。其harness功能现已全面可用，作为托管能力为模型提供基础架构：用户只需在配置中定义智能体（包括使用的模型、调用的工具、具备的技能和遵循的指令），AgentCore便会自动组装并运行整个循环。

该能力的两大特性使专业智能体团队变得切实可行：托管记忆按“参与者”和“会话”进行作用域划分，客户标识符（Actor ID）而非单个智能体决定了记忆范围，使每位专家都能读写相同的历史记录，且该记录在单个工作流执行结束后依然保留；工具、技能、模型和指令随每次调用传递，而非固定绑定在已部署的智能体上，使得一个智能体可以服务所有四位专家，无需分别配置四个独立资源。

实战演示：n8n中构建共享记忆的客服团队

文章以n8n编辑器为例，详细演示了如何构建一个由分流智能体和三名专家组成的客服团队：

• 分析专家：持有AgentCore代码解释器，负责计算类任务
• 架构专家：持有AWS技能目录，负责架构指导
• 研究专家：处理其他所有问题

整个流程仅需十个节点、两个凭证和一个harness资源。所有调用使用相同的Actor ID，因此每位专家都能读写相同的历史记录。演示中，客户质疑使用量数据，分析专家通过代码解释器实际执行Python计算（平均值为50,520次/天，超出限额520次），当客户追问如何优化时，架构专家无需客户重新提供数据，直接引用前次对话中的计算数据给出建议。

安全架构与运维优势

文章强调了该方案的安全特性：n8n仅负责触发、路由决策和回复，AgentCore在客户的AWS账户中运行智能体循环和持久化记忆，每个会话在独立的Firecracker微虚拟机中运行，无共享状态和文件系统。流量仅为出站方向，无需暴露任何内部服务到互联网。整个方案使用两个不同的IAM身份分别负责调用和执行，权限分离清晰。

成本与控制

AgentCore harness本身不收取额外费用，用户仅需为底层能力付费。托管记忆按标准收费（短期事件、长期记忆记录和检索请求）。该模板为所有四个智能体创建一个harness而非四个，显著降低了成本。

扩展与应用

文章最后提供了多种扩展方向：可通过Slack Trigger或Webhook从客户所在的平台触发工作流；可接入已通过CLI、控制台、CloudFormation或Terraform创建的既有harness；可添加更多专家智能体，接入远程MCP服务器或AgentCore Gateway实现API访问治理。该节点以MIT开源协议发布，AgentCore harness本身由AWS的开源代理框架Strands Agents提供支持。

中文翻译：

本认证节点聚焦栏目是一篇特邀客座文章，作者是AWS的Agentic AI基础架构负责人Sundar Raghavan。

一位客户给你的支持机器人发消息说，自从轮换了API密钥后，他们的夜间同步一直在失败。分流代理读取了消息，判断这是配置问题，然后移交给你的集成专家。专家问他们指的是哪个集成。

客户已经说过了。他们在四十秒前开启对话的那条消息里就说了，而且就在他们还在看的同一个会话线程里。从客户的角度来看，这是与同一家公司的单次对话。从工作流的角度来看，这是两个代理，而第二个代理接手时什么信息都没有。你可以把完整的对话记录传给每个专家，这在对话超出上下文窗口之前都有效。你也可以把历史记录放进向量数据库，这也有效，但这样一来你就得运维一个数据库和一套嵌入流水线。本文走的是第三条路。

Amazon Bedrock AgentCore是一个用于大规模构建、连接和优化代理的平台，支持任何框架或模型。AgentCore harness（现已全面可用）以托管能力的形式为模型提供脚手架：你通过配置定义代理，包括它使用的模型、调用的工具、可访问的技能以及遵循的指令，AgentCore会为你组装并运行整个循环。该能力的两大特性使专家团队模式变得切实可行。

AgentCore的托管记忆按参与者和会话进行作用域划分，因此使用标识客户而非单个代理的Actor ID，就能让每位专家读写相同的历史记录，而且该历史记录的存活时间超过单次工作流执行。此外，由于工具、技能、模型和指令随每次调用一起传递，而非固定在已部署的代理上，一个代理就能服务全部四位专家，无需部署四个代理。

在本文中，你将在n8n编辑器中构建这样一个支持团队：一个分流代理将每个传入问题分类并路由到三位专家之一——一位持有AgentCore代码解释器（Amazon Bedrock AgentCore的一项能力）负责计算，一位持有AWS技能目录负责架构指导，还有一位负责其他所有问题。回答第三类问题的专家已经知道第一位专家了解到的信息，无需运维向量存储，也无需部署任何基础设施。

本文内容

团队如何运作

图1：分流代理为每个问题选择一位专家。所有四个代理运行在同一个harness上，读写同一份客户记忆。

客户在“收到聊天消息时”节点中提出问题。“设置客户上下文”节点将聊天会话转换为客户标识符，每个代理随后都将其同时作为Actor ID和Session ID发送。分流代理读取问题并以JSON格式返回类别，“读取分流决策”节点对其进行解析。“路由到专家”节点将问题发送给匹配的代理，该代理使用为该调用授予的工具进行回答。“格式化回复”节点解包答案，“发布答案到Slack”节点将其发布，并标记产生该答案的专家。

由于每次调用携带相同的Actor ID，每位专家读写相同的历史记录，第二个问题因此受益于第一个问题。客户对使用量数据提出异议，分析专家计算出结果。客户接着询问如何重构，另一位专家无需再次被告知那些数据就能使用相同的数据来回答。

这一切在哪里运行，与它做什么同样重要，因为这决定了你需要运维什么。

图2：你的n8n实例持有工作流和凭证。AgentCore在你的AWS账户中运行代理，使用执行角色而非调用者的密钥。

职责划分很清晰。n8n负责触发器、路由决策和回复。AgentCore负责代理循环和比工作流运行更持久的记忆，并在各自的Firecracker微虚拟机中运行每个会话，无共享状态、无共享文件系统。画布上十个节点、两个凭证、一个harness资源而非四个。流量仅出站，因此你这边无需向互联网暴露任何内容：n8n使用SigV4对每个请求签名并调用AWS。两个IAM身份各司其职，下一节将进行配置。

开始之前

• 一个n8n实例。自托管或n8n Cloud均可与此节点配合使用。
• 安装节点。@aws/n8n-nodes-agentcore是经过验证的社区节点，你可以在节点面板中找到它。添加节点，搜索Amazon Bedrock AgentCore并选择它。你也可以通过“设置 > 社区节点 > 安装”输入@aws/n8n-nodes-agentcore进行安装。
• 一个AWS账户，可在支持的AWS区域中访问AgentCore harness。
• 在Amazon Bedrock控制台中启用一个基础模型。模型访问是按账户和按区域选择加入的，因此请在首次运行前启用你计划使用的Claude模型。
• 两个AWS IAM身份，详见下一节。
• 用于回复的Slack凭证。如果你更愿意在n8n中查看答案，可以删除该节点。

两个IAM身份

AgentCore harness使用两个独立的IAM主体，弄清它们的区别能省去大多数首次运行的调试工作。调用者是将其访问密钥填入n8n凭证的身份；它负责创建和调用harness。执行角色是代理在运行时以何种身份运行，因此它需要模型、代码解释器、技能目录和记忆的权限。

AgentCore harness安全指南包含两者的标准策略，其示例执行角色策略已涵盖此工作流使用的所有内容。节点仓库在docs/iam-trust-policy.json中提供信任策略，README将每个功能映射到其所需的策略块。首次运行时出现AccessDenied几乎都是执行角色上缺少某个操作，而不是调用者的问题。

尽可能使用来自AWS IAM Identity Center或AWS STS的临时凭证。

关于成本的说明：harness本身不单独收费。你仅为所使用的底层AgentCore能力付费，托管记忆按标准AgentCore记忆费率计费，包括短期事件、存储的长期记忆记录和检索请求。此工作流为所有四个代理创建一个harness，而非每个代理一个。完成后删除代理，并参阅Amazon Bedrock AgentCore定价。

获取工作流

将免费模板导入你的n8n实例以跟随操作。画布将加载全部十个节点，已连线并配置完成。

第1步：连接凭证

• 打开四个代理节点中的每一个，选择你的Amazon Bedrock AgentCore API凭证。
• 打开“发布答案到Slack”节点，选择你的Slack凭证。
• 在“设置客户上下文”节点中，将slackChannel设置为你机器人已加入的频道。

无需部署harness、无需构建容器、无需编写代理代码、无需配置向量存储。

运行前，检查画布上是否有任何节点带有警告标记。n8n在运行任何节点前会验证每个节点，因此一个未设置的凭证就会阻止工作流运行。

第2步：了解一个harness如何服务四个代理

打开“分流代理”节点。其“Harness ARN”字段为空，这指示节点在首次运行时创建代理，并在之后复用。在“配置选项”下，已启用托管记忆，包含语义、摘要和用户偏好策略。

图3：只有分流代理配置了harness。记忆在此配置，因为记忆是harness的属性而非单次调用的属性。

现在打开“分析专家”节点。其“Harness ARN”是一个表达式：

表达式
{{ $json.harnessArn }}

这是分流代理返回的ARN。该专家调用同一个harness而非创建自己的harness，并在该单次调用中为自己授予AgentCore代码解释器。“架构专家”以相同方式使用AWS技能目录。

按调用授予工具也降低了每位专家的成本，因为工具定义会计入模型输入令牌，即使代理从未调用该工具。此外，无论你配置什么，每个会话都自带两个内置工具——shell和file_operations，这就是“研究专家”无需配置任何内容就能工作的原因。

一个需要牢记的细节：“设置客户上下文”节点中的“代理名称”是harness的缓存键，因此也是团队记忆的缓存键。更改它会创建新的harness，累积的客户历史记录将无法再从工作流中访问。

第3步：客户询问账单问题

打开画布底部的聊天面板，发送一条真实客户会发送的消息，一条包含埋藏数字的消息：

你们的仪表盘显示我超出了每天50,000次API调用的套餐，但我自己记录的五个最忙日期的数据是41200、38900、52300、61800、58400。我平均真的超了吗？

首次运行需要两到三分钟，因为AWS正在配置代理。后续运行只需几秒即可回答。

图4：分流代理将此问题归类为分析类，因为回答它需要计算，因此路由到持有代码解释器的专家。

打开“分析专家”的输出并展开toolUses。其中包含代理编写并执行的Python代码：

Python
import statistics
calls = [41200, 38900, 52300, 61800, 58400]
print(statistics.mean(calls), statistics.pstdev(calls))

图5：AgentCore代码解释器在沙箱中运行Python，因此答案中的数字是执行输出的结果，而非对执行的预测。

平均值为50,520。客户确实超出了，在50,000的额度中每天超出520次，即百分之一。这里的答案是执行结果，追踪记录精确展示了是什么产生了它。在账单争议中，这个差异就是整个对话的核心。

第4步：同一位客户询问如何处理

留在同一个聊天中，发送一条不包含任何数字的后续消息：

这比我预想的更接近。我应该如何调整结构才能不再超限？

图6：另一位专家回答，并使用了第一个问题中的调用量数据。

分流代理将此问题归类为架构指导，并路由到另一位持有不同工具的代理：AWS技能目录而非代码解释器。该代理从未收到客户的调用量数据，但它仍然使用了这些数据，因为两次调用都指向同一个harness和相同的Actor ID。第一次交流被写入该客户的记忆，第二次调用读取了它。两位专家都不需要知道对方的存在。

这是支持团队能立即感受到的部分。没有共享记忆，客户会被要求在同一段对话中再次粘贴那五个数字，而面对的公司明明已经拥有这些数据。

在面向真实客户之前，有一个作用域细节需要注意：记忆事件按Actor ID加Session ID进行作用域划分，因此同一个harness上的不同Actor ID会获得完全独立的记忆。在此模板中，Actor ID来自聊天会话；在生产环境中，你应该将其设置为自己的用户、账户或工单ID。有关保留策略以及检索调优方式，请参阅“记忆”部分。

现在发送一条既不是计算也不是架构问题的消息：

另外，每日限额是在UTC午夜重置还是在我本地时间重置？

开放性问题路由到“研究专家”，它使用每个harness会话中都有的shell和文件工具。来自一位客户的三条消息、三位专家、一份持续累积的记忆。从客户的角度来看，这只是与一家公司的单次对话。

图7：每个答案到达Slack时都标记了产生它的专家。

后续方向

该模板是一个起点，以下每个方向都以与上述功能相同的方式配置。

从客户已经在的地方触发它。聊天面板无需任何设置，这就是模板自带它的原因。Slack触发器或Webhook是自然的生产环境选择；两者都需要一个可从互联网访问的n8n实例。

使用你已构建的代理。将某位专家的Harness ARN表达式替换为你通过AgentCore CLI、控制台、CloudFormation或Terraform创建的harness的ARN。该节点直接调用它，配置字段变为每次调用的覆盖项。

新增一位专家。在Switch上多一个分支，多一个代理节点。为它配置远程Model Context Protocol服务器、用于对你自有API进行受控访问的AgentCore Gateway，或AgentCore Browser。

关于私有VPC网络、OAuth认证调用、多提供商模型切换以及该节点支持的其他功能，请参阅AWS机器学习博客文章。

清理

该团队是你AWS账户中的一个harness资源，并且它配置了一个托管记忆存储。完成后请删除它以避免持续费用。

列出你的harness：

Bash
aws bedrock-agentcore-control list-harnesses --region us-west-2

然后删除此模板创建的那个support_team：

Bash
aws bedrock-agentcore-control delete-harness \
--harness-id --region us-west-2

由于该节点按“代理名称”复用同一个harness，测试此工作流无论你问了多少问题，都只会留下一个资源。

结论

你构建了一个由专家代理组成的团队，共享每位客户的同一份记忆，无需向量存储、数据库或任何已部署的基础设施。三个理念支撑了这一切：专家比通才做得更好，因为每位专家都拥有适合其工作的工具；以客户为作用域的记忆让团队能在成员之间交接工作，而无需客户重复自己；按调用授予工具意味着一个专家团队不必变成一堆独立资源来运维。

导入工作流即可将所有节点（已连线并配置完成）放入你的n8n实例。

有关该节点支持的其他功能，包括私有VPC网络和OAuth认证调用，请参阅AWS机器学习博客上的《在n8n中使用Amazon Bedrock AgentCore harness运行生产级AI代理》。要了解底层能力的更多信息，请参阅AgentCore文档。

该节点以MIT许可证开源。AgentCore harness本身由Strands Agents驱动，这是AWS的开源代理框架。欢迎在GitHub仓库上贡献代码和提供反馈。

英文来源：

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 is a platform to build, connect, and optimize agents at scale, with any framework or model. AgentCore harness, 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 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, 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.
In this post
How the team works
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.
Before you start

• An n8n instance. Self-hosted or n8n Cloud both work with this node.
• The node installed. @aws/n8n-nodes-agentcore is a verified community node, so you can find it in the nodes panel. Add a node, search for Amazon Bedrock AgentCore, and select it. You can also install it from Settings > Community Nodes > Install by entering @aws/n8n-nodes-agentcore.
• An AWS account with access to AgentCore harness in a supported AWS Region.
• A foundation model enabled in the Amazon Bedrock console. Model access is opt-in per account and per Region, so enable the Claude model you plan to use before the first run.
• Two AWS IAM identities, described in the next section.
• A Slack credential for the reply. Delete that node if you would rather read the answer in n8n.
  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 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, and the README 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.
  Get the workflow
  Import the free template to your n8n instance to follow along. The canvas will load with all ten nodes wired and configured.
  Step 1: Connect your credentials
• Open each of the four agent nodes and select your Amazon Bedrock AgentCore API credential.
• Open Post Answer To Slack and select your Slack credential.
• In Set Customer Context, set slackChannel to a channel your bot has joined.
  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.
  Step 2: See how one harness serves four agents
  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.
  Step 3: The customer asks about their bill
  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.
  Step 4: The same customer asks what to do about it
  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 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.
  Where to go from here
  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 server, an AgentCore Gateway for governed access to your own APIs, or the AgentCore Browser.
  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.
  Clean up
  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:
  Bash
  aws bedrock-agentcore-control delete-harness \ --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.
  Conclusion
  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 on the AWS Machine Learning Blog. To learn more about the underlying capability, refer to the AgentCore documentation.
  The node is open source under MIT. AgentCore harness itself is powered by Strands Agents, the open source agent framework from AWS. Contributions and feedback are welcome on the GitHub repository.