New community node: Amazon Bedrock AgentCore — run production-grade AI agents in your workflows

Built with n8n
,
1

Hey folks,

We just published a community node for Amazon Bedrock AgentCore — it lets you run production-grade AI agents directly inside your n8n workflows, without writing any infrastructure or agent code.

The motivation: n8n’s built-in AI Agent node is great for simple cases, but I kept hitting walls — no real cross-session memory, no real browser or code execution, short timeouts. AgentCore’s managed agent “harness” solves those, so I wrapped it in a node that feels like any other AWS node in n8n (same credential pattern as the Lambda/S3 nodes).

What you can do with it:

  • Cross-session memory that persists across runs (auto-provisioned — nothing to set up)
  • Any model, switchable mid-session — Bedrock, OpenAI, Gemini, or any LiteLLM-supported provider
  • Real tools — a cloud browser, a sandboxed code interpreter, AgentCore Gateway, and remote MCP servers
  • Inline functions — let the agent call back into your n8n workflow and hand it a result
  • Skills — pull domain knowledge on demand from the AWS catalog, Git, or S3
  • Run it your way — in your VPC, with a custom container, and with persistent file storage
  • Plus OAuth-protected invoke and versioned endpoints for staging/prod

It just went to v0.2 with the full AgentCore harness GA feature set. There are a handful of ready-to-import example workflows in the repo if you want to try it fast.

Install it from Settings → Community Nodes → @aws/n8n-nodes-agentcore

Would genuinely love feedback and what you’d want next. And if you build something cool with it, drop it in the thread. :raising_hands:

2

Welcome @rsundaraws!

The cross-session memory gap in n8n’s built-in AI Agent is a real friction point - right now the workaround is using a Postgres or Redis Memory node, but that still doesn’t help with code execution or browser tools. Having those as managed infrastructure in AgentCore while keeping the same credential pattern as Lambda/S3 is a clean integration design.

One use case this fits well is long-running research agents where you need the browser tool to pull live data and the code interpreter to process it - something n8n’s native agent can’t do in a single session today.

1 Like
3

Thanks @nguyenthieutoan — appreciate the warm welcome and the thoughtful breakdown.

You nailed the exact friction this addresses. The Postgres/Redis memory workaround works for basic recall, but it’s still on you to configure the persistence, manage the schema, and handle session boundaries. With managed memory here, the harness owns that lifecycle, you just set a session ID and it handles the rest across turns.

The research agent use case you described (browser for live data + code interpreter to process it) is a great example. You can configure both tools on the same agent and they share the session context, so the code interpreter can reference what the browser pulled without you piping data between nodes manually.

If you get a chance to try it, I’d be curious to hear how it fits your workflows, especially if there are rough edges. The node is still early and feedback from builders who are actually hitting these limits with the native agent is exactly what shapes what comes next.