n8n and Amazon Bedrock AgentCore: Orchestrate Workflows, Run Agents in Production

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is in maintenance for new customers after July 30, 2026. Net-new agent builds should use Bedrock AgentCore. Full matrix: lifecycle roundup.

Building an AI agent is increasingly a weekend prototype. Operating several agents inside real business processes — ticket queues, CRM stages, approval chains, overnight batch jobs — is a different problem.

On June 17, 2026, AgentCore Harness reached general availability: a managed, config-driven agent loop on the same platform as Runtime, Memory, Gateway, and Identity (What’s New). AWS then shipped a verified n8n community node, @aws/n8n-nodes-agentcore, so a workflow can invoke that harness without you writing the agent loop (AWS ML Blog, n8n listing).

The architecture that holds up is not “n8n as the agent platform.” It is:

n8n orchestrates the business process. Amazon Bedrock AgentCore runs the agent.

First-party signals we reuse (not a combined n8n + AgentCore load test) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Support-style AgentCore platform TCO silhouette: 50K sessions/mo ~$791/mo plus model (decision guide). Self-host n8n on EKS often lands ~$500+/month in us-east-1 versus n8n Cloud until execution volume is high — EKS guide. Model AgentCore lines on the pricing calculator.

Reproduce this — Decision gates live under examples/architecture-blog-2026/n8n-agentcore/: responsibility matrix, IAM caller vs execution role, Monday checklist. Official node examples (importable workflows) are in the AWS n8n-nodes-agentcore repo.

Opinionated take: pin a Harness ARN (and a named endpoint when you version) in every production n8n workflow. Leave the ARN blank only in non-prod so the node can auto-provision. The trade-off is extra AWS control-plane work versus n8n-driven harness drift.

AI agents need more than an LLM

A Converse call plus a clever system prompt is not a production agent. The moment the model must touch enterprise systems, the missing pieces show up as outages, surprise bills, or silent wrong writes.

The B2B CRM assistant silhouette above is why tool round-trip and Policy belong on Gateway, not in a pile of n8n HTTP nodes the model cannot be constrained from calling.

What broke — Teams that treated n8n’s built-in AI Agent node as the production runtime hit the gap the AWS node README states plainly: memory, code, and browser then run in (or beside) the shared n8n process, sessions die with the execution timeout, and you operate the stores yourself. Detection: first multi-tenant conversation leaked or a long research turn hit the workflow timeout. Fix: invoke AgentCore Harness via @aws/n8n-nodes-agentcore; keep n8n for routing and approvals. Related counter-case: scaling n8n main replicas without EXECUTIONS_MODE=queue duplicates workflow runs — EKS checklist.

What n8n does best

n8n is a workflow automation and integration platform: a visual engine that connects SaaS, APIs, databases, webhooks, and (now) AWS agent infrastructure.

Use it for:

• Event-driven entry — webhooks from ticketing, CRM, or API Gateway.
• Scheduled jobs — nightly exception queues, weekly digest generation.
• Deterministic branching — if priority = P1, if amount > threshold, if region = EU.
• Human-in-the-loop — Wait / approval nodes before irreversible writes.
• Glue — map fields, enrich from a database, post to Slack, patch the system of record.

That is workflow orchestration: you specify the graph. The next node is not a surprise.

Agent runtime is the opposite shape. The model chooses tools, how many times to call them, and when to stop. You still need a loop, a sandbox, memory, and identity around that non-determinism. n8n should wrap that loop, not become it.

Built-in AI Agent node vs AgentCore node

From the AWS node README (capability table, not a FactualMinds benchmark):

n8n’s AI Agent node is a reasonable fit for a single model call inside a workflow. Production agents that need isolation, managed memory, Browser, or Code Interpreter should go through Harness.

What Amazon Bedrock AgentCore brings

AgentCore is a modular agent platform: build, deploy, and operate agents with supported frameworks and foundation models, without you owning the isolation layer (overview). The n8n node talks to Harness. The rest of the platform is what Harness sits on — do not skip it because the editor looks like a single node.

Mentioned, not designed here: Payments, Registry, Optimization, Runtime Instances. See What this post doesn’t cover.

Harness vs Runtime stay in the production guide. If the product is a custom graph, export to Strands on Runtime rather than encoding hop caps as n8n IF nodes.

Combined architecture

Business events (APIs, webhooks, schedules)
        │
        ▼
n8n — routing, approvals, SaaS/API orchestration
        │
        ▼
Amazon Bedrock AgentCore Harness
  Runtime isolation · Memory · Gateway · Identity · Browser/CI
        │
        ├── Amazon Bedrock / configured model providers
        ├── Enterprise data and APIs (via Gateway)
        └── External services (MCP, OAuth tools)
        │
        ▼
n8n — results, human approval, CRM/ERP/notifications

Conceptual flow

1. A business event hits n8n (webhook, queue, cron).
2. The workflow collects deterministic context (customer id, ticket fields, region).
3. n8n invokes a pinned Harness with Session ID (and Actor ID when Memory is on).
4. The harness runs the loop in an isolated microVM; tools go through Gateway, Browser, Code Interpreter, or an inline function back into n8n.
5. The node returns the completed result (it consumes the AgentCore event stream; it does not yet forward partial tokens into n8n’s streaming UI — node README).
6. n8n continues: approval branch, system-of-record update, notify.

Inline functions are a documented HITL inside the agent turn: the invocation returns stopReason: "tool_use", the workflow computes or collects a human result, a second node placement on the same Session ID sends Tool Results, and the agent resumes. That is not a substitute for n8n approval nodes on irreversible business writes.

Responsibility matrix

Full RACI: responsibility-matrix.md.

Two Harness ARN modes

Documented by AWS and the node — not optional folklore:

What broke — Shipping a production workflow with Harness ARN blank. The node owned lifecycle: config edits in n8n updated the live harness, lab Force Recreate created extra resources, and cleanup was a console archaeology exercise. Detection: Cost Explorer / list-harnesses showed harnesses with no owner tag. Fix: create the harness via CLI/console/Terraform, pin ARN + named endpoint, delete unused lab harnesses.

Assumes AWS CLI v2 with AgentCore support, a supported Region, and credentials that can list/delete harnesses. Confirm names against current CLI help.

aws bedrock-agentcore-control list-harnesses --region us-west-2
aws bedrock-agentcore-control delete-harness --harness-id <harness-id> --region us-west-2

Example use cases

These are process shapes, not certified connectors. Wire whatever ticketing or CRM APIs you already have.

Customer support

Ticket webhook → n8n loads customer and order records with deterministic HTTP/DB nodes → invoke a support Harness with Actor ID = customer and Session ID = ticket id → agent drafts a reply or recommended action using Gateway tools (read-only first) → if sentiment/amount/policy flags, n8n Wait for a human → n8n posts the approved reply and status back to the ticketing API.

Keep write tools behind Gateway Policy. Do not let the agent POST a refund because the prompt said “be helpful.”

Sales / CRM intelligence

New-lead webhook → n8n enrich (clearbit-class HTTP, internal account API) → invoke an analysis Harness → agent returns structured recommendations (fields you validate) → optional human review on strategic accounts → n8n patches CRM.

The Gateway canary (~180 → ~95 ms on 12 tools) is the reason to put enrichment tools the agent must choose among on Gateway, and keep the CRM patch in n8n after validation.

Operations / back-office

Schedule or queue event → n8n gathers batch context → agent analyzes and calls approved tools (Code Interpreter for stats, Gateway for internal APIs) → n8n fans out to downstream systems → exceptions to a human queue.

The AWS examples folder includes a campaign-statistics template (webhook → Code Interpreter → n8n recomputes and labels → Slack). Use it as a pattern: agent proposes, workflow verifies, then notify.

When n8n should not be the agent runtime

n8n is the wrong place to run the agent loop when any of these are true:

• Isolation — untrusted prompts or multi-tenant data must not share the n8n Node process.
• Identity — you need inbound JWT and on-behalf-of tool calls. Harness security: SigV4 callers do not get per-user Identity token-vault / on-behalf-of scoping; configure inbound OAuth on the harness.
• Long-running work — research, browser tasks, or async agents that outlive a workflow execution timeout.
• Governed tools — write APIs that need Cedar Policy, not an n8n credential with *.
• Observability and evals — you need AgentCore/CloudWatch GenAI traces and Evaluations on sessions, not only “workflow succeeded.”
• Custom topology — supervisors with hop caps, A2A, Graph/Swarm. That is Runtime + Strands, invoked from n8n if you still want process glue.

If the job is one model call with no tools and no memory, you may not need AgentCore at all — Converse or Knowledge Bases may be enough. If the job is employee knowledge work with connectors and seats, compare AgentCore vs Quick Suite.

Reference architecture for AWS customers

Options, not a mandate.

Where n8n runs

• n8n Cloud — the verified node installs (instance owner, one-time). Fastest path; weaker VPC/IRSA story.
• Self-hosted on Amazon EKS — RDS PostgreSQL Multi-AZ, queue mode + Redis/Valkey, IRSA, ALB + WAF. Details: How to host n8n on AWS EKS. Light/medium self-host often ~$500+/month before you beat Cloud on execution volume — re-quote.

How n8n talks to AgentCore

• Node uses the same credential pattern as other AWS nodes: access key + secret (+ session token for STS).
• Prefer IAM Identity Center / STS temporary credentials. Do not commit keys.
• Execution role ARN on the credential is assumed by AgentCore, not by n8n locally.
• For inbound-OAuth harnesses: control plane stays SigV4; invoke sends Authorization: Bearer with a JWT you store on the credential (node README).

VPC agents

Set Network Mode = VPC on the credential (subnets + security groups). AWS: subnets need no internet if you create the listed VPC endpoints — ECR API/DKR, S3 gateway, and Bedrock Runtime if the agent calls Bedrock. First VPC harness create can take minutes; the node waits up to 10 minutes. Canonical list: Harness network configuration.

Logging

• AgentCore: CloudWatch GenAI observability / OTEL spans for the loop and tools.
• n8n: workflow execution history. Do not expect one dashboard to be both.

Separation

n8n host IRSA (Secrets Manager, optional S3 workflow export) ≠ caller IAM in the AgentCore credential ≠ harness execution role. Three identities. Collapse them and you cannot answer “who invoked the refund tool.”

Security considerations

Follow Harness security and AgentCore security. Do not paste a broad policy from a blog.

• Least privilege — caller gets the callers table, scoped to harness ARNs; execution role gets the sample policy plus optional feature blocks you actually use (IAM split).
• Secrets — N8N_ENCRYPTION_KEY in Secrets Manager + KMS. Agent API keys and OAuth client secrets belong in AgentCore Identity credential providers, not in workflow JSON.
• API authentication — SigV4 for invoke unless you need per-user identity, then inbound JWT with tight aud / client / scope / claims.
• Tool permissions — Gateway Policy on writes; Browser and Code Interpreter off by default.
• Data boundaries — Actor ID + Session ID for Memory; never a shared global notebook for multi-tenant SaaS.
• Human approval — n8n Wait nodes for high-impact side effects even if Gateway would allow the tool.
• Audit — CloudTrail on bedrock-agentcore.amazonaws.com; retain n8n execution logs with access control.
• Trust boundary — anyone who can InvokeHarness reaches the tools on that harness. Validate prompts in n8n before invoke if callers are not fully trusted. The harness does not treat prompt text as a policy engine.
• Model overrides — additionalParams / apiBase / modelId on invoke are pass-through. Do not expose those fields on an n8n webhook you do not trust.

Architecture principles

1. Keep workflow orchestration separate from agent reasoning. n8n owns the graph; Harness owns the loop.
2. Treat agents as production workloads. Isolation, IAM, spend alarms, versioned endpoints — not a prompt in a Code node.
3. Give agents only the tools they require. Gateway + Policy; disable Browser/CI until an intent needs them.
4. Use deterministic workflows around non-deterministic reasoning. Validate structured output in n8n before writes.
5. Human approval for high-impact actions. Inline functions for in-loop questions; Wait nodes for irreversible business writes.
6. Design for observability from day one. AgentCore traces and n8n history; Evaluations before you scale session volume.
7. Keep enterprise integrations behind controlled interfaces. Systems of record stay behind Gateway or explicit n8n nodes — not raw credentials in the model context.

What to Do This Week

1. Install @aws/n8n-nodes-agentcore on a non-prod instance; pin a version.
2. Create two IAM principals; put temporary caller keys and the execution role ARN on the n8n credential.
3. Auto-provision once, copy the Harness ARN, then clone the workflow with ARN pinned.
4. Inventory tools: reads on Gateway/MCP; writes behind Policy; Browser/CI off.
5. Add Actor ID / Session ID expressions from your ticket or user id — blank session IDs reset memory every run.
6. Run the Monday checklist and price the mix on the AgentCore calculator.

As an AWS Partner, FactualMinds works with organizations designing cloud-native AI architectures that connect generative AI capabilities with existing enterprise systems and operational workflows — including n8n on EKS and AgentCore Harness/Runtime cutovers. Contact us if you want a production-readiness review (pin-ARN, IAM split, Gateway Policy, Memory TTL). Related services: Amazon Bedrock consulting · Generative AI on AWS. Glossary: Bedrock AgentCore.

What This Post Doesn’t Cover

• AgentCore Runtime Instances (EC2 capacity providers, 14-day sessions) — Runtime Instances GA.
• Payments, Registry, Optimization product setup.
• Full IAM JSON — AWS’s harness security guide is the source of truth and changes with features.
• A combined n8n + Harness latency or cost test we ran for this article. Cited numbers are from earlier FactualMinds posts and AWS’s own first-run timing (~30–60 s create).
• n8n Cloud vs EKS TCO re-benchmark as of this publish date — re-quote.
• GovCloud / every Region matrix — confirm AgentCore Regions before procurement language.

We have not re-measured Gateway ~180→95 ms on a workflow that also includes n8n HTTP overhead. Treat that canary as AgentCore-side tool RTT, then measure your orchestrator separately.