Run production AI agents in n8n with Amazon Bedrock AgentCore harness

來源原標題

Run production AI agents in n8n with Amazon Bedrock AgentCore harness

作者

Sundar Raghavan

原始標籤

Advanced (300) · Amazon Bedrock · Amazon Bedrock AgentCore · Technical How-to

原始連結

https://aws.amazon.com/blogs/machine-learning/run-production-ai-agents-in-n8n-with-amazon-bedrock-agentcore-harness/

摘要原文

If you build and automate workflows in n8n without writing much code, you’ve probably used its AI Agent node to add a model call to a workflow. It’s a great start. But a production agent needs more than a single model call: memory that lasts beyond one run, tools it can actually use like a browser or a code sandbox, and room to work through longer tasks. Building that scaffolding yourself is the hard part. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. AgentCore harness, a capability of Amazon Bedrock AgentCore, is now generally available and provides that scaffolding for you. A new open-source community node brings it into n8n’s visual editor. You get production agents with persistent memory, real tools, and the model provider of your choice, without writing infrastructure or agent code. You’re not tied to one model either. The node works with Amazon Bedrock, OpenAI, Google Gemini, and LiteLLM-supported providers, and you can switch providers between turns of the same conversation. In this post, you will install the node, @aws/n8n-nodes-agentcore , and build agents step by step in the n8n editor. You will start with an agent that remembers a conversation, scope memory to individual users, add a code interpreter tool, give the agent skills, and finish by running an agent privately in your own virtual private cloud (VPC). The node is open source under the MIT license, and AgentCore harness is powered by Strands Agents , the open source agent framework from AWS. An agent is more than a model. The model reasons, but the harness does the work around it: it runs the orchestration loop, calls tools, manages the context window, keeps state across turns, recovers from failures, and isolates each session. Building that layer is where most teams spend their time. AgentCore harness gives you that layer 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. Each session runs in its own isolated environment with a filesystem and shell, memory across sessions, and web browsing. When configuration isn’t enough, you can export the harness to Strands code and keep running on the same system. n8n’s built-in AI Agent node is a good fit for a single model call in a workflow. The community node goes further by exposing the full harness in the n8n editor. It has one operation with a single deciding field, Harness ARN : The node uses the same AWS credential pattern as the existing n8n AWS Lambda and Amazon Simple Storage Service (Amazon S3) nodes , so it feels familiar if you already automate AWS services in n8n. Before you begin, make sure you have the following: Important: Where you can, use temporary credentials from AWS IAM Identity Center or AWS Security Token Service (AWS STS), and follow the principle of least privilege when you configure IAM permissions. Don’t commit credentials to source control. Note on cost : The AgentCore harness, the managed memory store it provisions, and (if you use it) VPC endpoints are billed AWS resources. Follow the Clean up section at the end to remove what you create for this walkthrough, and refer to the AgentCore documentation for pricing. You configure the AWS credential once, the same way you would for other AWS nodes in n8n. Amazon Bedrock AgentCore API credential in n8n, showing the access key, Region, and execution role ARN, with a successful connection test In this walkthrough, you build an agent that remembers details across turns of a conversation. Memory is on by default, so the node provisions a managed memory store for you and there’s nothing extra to configure. The first run takes about 30-60 seconds while AWS provisions the agent. The output includes the agent’s response, token usage, and a summary of what the node provisioned, including the memory store it created for you. Turn 1. The node output shows the agent’s response and a harness summary that confirms managed memory with a provisioned memory ARN. Now change only the Prompt to Suggest one destination and one dish I’d enjoy, based on what you know about me , keep the same session ID, and run again. Turn 2. The agent recalls the preferences from turn 1, warm beaches and vegetarian, because the conversation persisted through the same session ID. The output field sessionSource reads provided when you supply a session ID, and the input token count rises on turn 2 because the node loads the prior conversation before the agent reasons. If you leave the session ID blank, each run starts a new conversation. When one agent serves many people, you can keep each person’s memory separate with an Actor ID . Memory is scoped by actor and session, so different actors get isolated histories from the same agent. The scoping is a hierarchy: the agent holds the shared configuration, the Actor ID isolates one user’s memory from another’s, and the Session ID isolates individual conversations within an actor. One actor can have many sessions. A different actor with the same session ID still gets its own separate memory. The node configured with an actor ID and session ID for a specific user. Turn 1 for the actor user-alice, which stores a preference. Turn 2 for the same actor. The agent returns the value it stored for this user. A different actor ID keeps its own separate memory. Agents become far more capable when they can use tools. In this walkthrough, you give the agent a code interpreter that runs code in a sandboxed environment. The agent writes and runs code in the sandbox and returns computed results for the mean, median, and standard deviation, rather than estimating them. The harness summary shows one tool configured. You add other tools the same way, including a cloud browser, AgentCore Gateway (a capability of Amazon Bedrock AgentCore), and remote Model Context Protocol (MCP) servers. Skills are bundles of instructions and scripts that give an agent domain knowledge on demand. You load them from the AWS curated catalog, a Git repository, Amazon S3, or a filesystem path, and the harness loads them only when the task calls for them. The agent applies the loaded skills to produce guidance, and the harness summary shows the number of skills configured. For agents that need private network access, you can run the harness in your VPC. You set the network configuration on the credential, so every agent that credential provisions runs privately. The credential configured for VPC mode with subnet and security group IDs. Your subnets don’t need internet access. The harness pulls its managed container image from a private Amazon ECR repository in the same Region, so you need VPC endpoints for Amazon ECR and Amazon S3 rather than a NAT gateway. Refer to the AgentCore harness network configuration documentation for the required endpoints and the execution role permissions. Refer to the AgentCore harness security documentation for the required endpoints and the execution role permissions. The node output for a VPC agent. The harness summary shows the network mode is VPC. Each agent you create is a harness resource in your AWS account, and it can provision a managed memory store. To avoid ongoing charges, delete the agents you no longer need. If you enabled a VPC, you might also want to remove any interface VPC endpoints you created for this walkthrough, because interface endpoints incur charges while they exist. This post walked through memory, per-user scoping, a code interpreter tool, skills, and VPC networking. The node already supports more of the Amazon Bedrock AgentCore harness feature set. Here’s what to try next, each configured the same way you configured the features above: The examples folder in the GitHub repository includes importable workflows for many of these.