n8n’s built-in AI Agent node is fine for a single model call dropped into a workflow. It falls apart the moment you need memory that survives between runs, a tool the agent can actually execute, or isolation between users. Building that scaffolding yourself is where most teams lose weeks.
Amazon Bedrock AgentCore harness is now generally available and handles that layer for you. A new open-source community node, @aws/n8n-nodes-agentcore, brings it into the n8n visual editor. You get persistent memory, a sandboxed code interpreter, skills, and optional VPC networking, without writing any infrastructure or agent code. The node is MIT licensed and built on Strands Agents, the open-source agent framework from AWS.
What AgentCore harness actually does
A model reasons. The harness does everything around it: runs the orchestration loop, calls tools, manages the context window, persists state across sessions, recovers from failures, and isolates each session in its own environment with a filesystem and shell.
You define the agent in configuration: which model it uses, which tools it calls, which skills it loads, and what instructions it follows. AgentCore assembles and runs the loop. The node works with Amazon Bedrock, OpenAI, Google Gemini, and LiteLLM-supported providers, and you can switch providers between turns of the same conversation without losing context.
The node has one key field: Harness ARN. Leave it blank and the node creates an agent on the first run, reuses it on later runs, and updates it when your configuration changes. Paste an existing ARN and it invokes that agent directly. It uses the same AWS credential pattern as the existing n8n Lambda and S3 nodes, so the setup feels familiar.

️ Prerequisites
- An n8n instance, either self-hosted or on n8n Cloud
- The community node installed: search for Amazon Bedrock AgentCore in the nodes panel, or go to Settings > Community Nodes and install
@aws/n8n-nodes-agentcore(this guide uses version 0.3) - An AWS account with access to AgentCore harness in a supported AWS Region
- AWS credentials for the caller identity with harness caller permissions, plus a separate IAM execution role the harness assumes at runtime
Use temporary credentials from AWS IAM Identity Center or AWS STS where you can. Do not commit credentials to source control. The AgentCore harness, its managed memory store, and any VPC endpoints are billed AWS resources. Run the cleanup commands at the end of this guide when you finish testing.
Step 1: Configure the credential
- 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, plus a Session Token if you use temporary credentials.
- Select your Region and enter the Execution Role ARN the harness assumes at runtime.
- Choose Test to confirm the connection, then Save.
Step 2: Build an agent with persistent memory
Memory is on by default. The node provisions a managed memory store for you the first time it runs, with nothing extra to configure.
- Add a manual trigger to a new workflow, then add the Amazon Bedrock AgentCore node and attach your credential.
- Leave Harness ARN blank.
- 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 and a Session ID, such as
demo-travel-session. Reusing the same session ID on later runs is what continues the conversation. - Enter a first-turn prompt, such as “I love warm beaches and I’m vegetarian. Note that for me.”, and run the node.
The first run takes 30 to 60 seconds while AWS provisions the agent. The output includes the agent’s response, token usage, and a harness summary confirming the managed memory store and its provisioned ARN. On the second run, change only the prompt to something like “Suggest one destination and one dish I’d enjoy, based on what you know about me.” The agent recalls the preferences from turn 1 because the conversation persisted through the session ID.
If you leave the session ID blank, each run starts a fresh conversation. The sessionSource field in the output reads provided when you supply an ID. The input token count rises on turn 2 because the node loads the prior conversation before the agent reasons.
Step 3: Scope memory per user with an actor ID
When one agent serves multiple users, you need their memory isolated from each other. The Actor ID field handles this. Memory is scoped by actor and session: different actors get isolated histories from the same agent, and a different actor with the same session ID still gets its own separate 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: “Remember my project is codenamed Aurora.”
- Change the prompt to “What’s my project codename?” and run again with the same actor and session IDs.
The agent returns the stored value for that actor. A different actor ID starts with no shared memory, even if the session ID is identical.
Step 4: Add a code interpreter tool
Tools are where agents stop being chatbots and start being useful. The AgentCore Code Interpreter runs code in a sandboxed environment, so the agent can compute rather than estimate.
- Turn on Add Tools, then under Tools, choose Add Tool and set Type to AgentCore Code Interpreter.
- In the System Prompt, instruct the agent to write and run code to answer questions, then report the result.
- Enter a prompt that requires real computation, such as “Generate 500 random exam scores between 0 and 100, then report the mean, median, and standard deviation.”
The agent writes and executes code in the sandbox and returns computed results rather than estimates. The harness summary shows one tool configured. You add other tools the same way: a cloud browser, AgentCore Gateway, and remote MCP servers all appear in the same tools list.

Step 5: Load skills
Skills are bundles of instructions and scripts that give an agent domain knowledge on demand. The harness loads them only when the task calls for them. You can pull skills from the AWS curated catalog, a Git repository, Amazon S3, or a local filesystem path.
- Turn on Add Skills, choose Add Skill, and set the Source. For the curated catalog, choose AWS Skills and enter a glob pattern such as
core-skills/*. - Optionally add a second skill with a Git source pointing to a public repository.
- Enter a prompt that benefits from the loaded skills, such as “Outline a serverless image-upload pipeline on AWS.”
The harness summary in the output shows the number of skills configured. The agent applies the loaded skills to produce its guidance.
Step 6: Run the agent in your VPC
For agents that need access to private network resources, you can run the harness inside your own VPC. The network configuration lives 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.
Your subnets do not need internet access. The harness pulls its managed container image from a private Amazon ECR repository in the same Region. You need VPC endpoints for Amazon ECR and Amazon S3 rather than a NAT gateway. Refer to the AgentCore harness security documentation for the required endpoints and execution role permissions.
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 what you created for this walkthrough.
List your harnesses:
aws bedrock-agentcore-control list-harnesses --region us-west-2Delete the ones you no longer need:
aws bedrock-agentcore-control delete-harness --harness-id <harness-id> --region us-west-2If you created VPC interface endpoints for this walkthrough, remove those too. Interface endpoints incur charges while they exist.
What else the node supports
This guide covered memory, per-user scoping, the code interpreter, skills, and VPC networking. The node already supports more of the AgentCore harness feature set:
- Model provider switching mid-session. Use OpenAI, Google Gemini, or LiteLLM-supported providers alongside Amazon Bedrock. Switch between turns without losing context. Non-Bedrock providers use an API key stored in AgentCore Identity.
- More tools. Cloud browser, AgentCore Gateway with optional OAuth outbound authentication, and remote MCP servers.
- Inline functions. Let the agent call back into your n8n workflow for a human-in-the-loop step, then return the result to the agent.
- Custom containers. Bring your own Linux/arm64 container image so the agent runs with your own dependencies.
- Filesystem mounts. Managed session storage, or mount Amazon EFS or Amazon S3 for data that outlives a session.
- Versions and endpoints. Every configuration change becomes an immutable version. Named endpoints let you pin staging and production to specific versions.
Importable example workflows live in the GitHub repository’s examples folder. The examples/templates folder has fuller workflows showing the agent working alongside other n8n nodes in complete automations.


