Amazon Bedrock AgentCore、n8n で本番 AI エージェントを運用可能に

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.

What the node does

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:

• Leave it blank and the node creates an agent for you on the first run, reuses it on later runs, and updates it when your configuration changes.

• Paste an existing harness ARN and the node invokes that agent directly, so you can use agents you created outside n8n.

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.

Prerequisites

Before you begin, make sure you have the following:

• An n8n instance. You can run n8n either as a self-hosted install or on n8n Cloud. Both work with this node. If you’re new to n8n, see the n8n deployment documentation to choose an option and set up your instance, then complete the initial sign-in so you land in the editor where you will build the workflows in this post.

• The node installed. @aws/n8n-nodes-agentcore is a verified community node, so you can find it directly in the n8n nodes panel. In the editor, add a node, search for Amazon Bedrock AgentCore, and select it — n8n installs it for you. (You can also install it from Settings, Community Nodes, Install by entering @aws/n8n-nodes-agentcore.) This post uses node version 0.3.

• An AWS account with access to AgentCore harness in a supported AWS Region.

• AWS credentials for the caller (the identity whose keys go in the n8n credential) with the harness caller permissions, plus a separate AWS Identity and Access Management (IAM) execution role that the harness assumes at runtime. AWS maintains the least-privilege reference policies in AgentCore harness security documentation and the node README maps each feature to the permissions to add.

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.

Set up the credential

You configure the AWS credential once, the same way you would for other AWS nodes in n8n.

• In n8n, go to Credentials and choose New.

• Search for and select Amazon Bedrock AgentCore API.

• Enter your Access Key ID and Secret Access Key, and a Session Token if you use temporary credentials.

• Select your Region and enter the Execution Role ARN that the harness assumes at runtime.

• Choose Test to confirm the connection, then choose Save.

Amazon Bedrock AgentCore API credential in n8n, showing the access key, Region, and execution role ARN, with a successful connection test

Build your first agent and give it memory

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.

• Add a manual trigger to a new workflow, add the Amazon Bedrock AgentCore node after it and attach your credential.

• Leave Harness ARN blank so the node creates and reuses the agent.

• Enter an Agent Name, such as travel_concierge.

• Set Model Provider to Amazon Bedrock and enter a Model ID, such as a Claude model.

• Enter a System Prompt, such as You are a warm, concise travel concierge, and a Session ID, such as demo-travel-session. Reusing this session ID is what continues the conversation on later runs.

• Enter a Prompt for the first turn, such as “I love warm beaches and I’m vegetarian. Note that for me.”, and run the node.

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.

Scope memory per user with an actor ID

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.

• Use an agent such as team_assistant with managed memory.

• Under Additional Options, set Actor ID to a per-user value, such as user-alice, and set a Session ID for that user.

• Run a first turn, such as Remember my project is codenamed Aurora.

• Change the prompt to What’s my project codename? and run again with the same actor and session.

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.

Add a tool: run code in a sandbox

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.

• Use an agent such as data_analyst with a Claude model.

• In the System Prompt, instruct the agent to write and run code to answer, then report the result.

• Turn on Add Tools, then under Tools, choose Add Tool and set Type to AgentCore Code Interpreter, a capability of Amazon Bedrock AgentCore.

• Enter a Prompt that requires computation, such as “Generate 500 random exam scores between 0 and 100, then report the mean, median, and standard deviation.”, and run the node.

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.

Give the agent skills

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.

• Use an agent such as aws_architect with a Claude model.

• Turn on Add Skills, then under Skills, choose Add Skill and set the Source. For the curated catalog, choose AWS Skills and enter a glob pattern such as core-skills/*. You can add more skills, for example a Git source that points to a public repository.

• Enter a Prompt that benefits from the skill, such as “Outline a serverless image-upload pipeline on AWS”, and run the node.

The agent applies the loaded skills to produce guidance, and the harness summary shows the number of skills configured.

Run in your VPC

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.

• Edit your Amazon Bedrock AgentCore API credential.

• Set Network Mode to VPC.

• Enter your VPC Subnet IDs and VPC Security Group IDs, then save.

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.

• In a workflow, use an agent such as private_vpc_agent with the VPC-enabled credential.

• Enter a Prompt and run the node.

The node output for a VPC agent. The harness summary shows the network mode is VPC.

Clean up

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.

• List your harnesses with the AWS Command Line Interface (AWS CLI) or the Amazon Bedrock AgentCore console.

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

• Delete the ones you created for this post. For pricing details, refer to the AgentCore documentation.

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

If you enabled a VPC, you might also want to remove any interface VPC endpoints you created for this walkthrough, becaus