Building an n8n AI agent is genuinely easy. Connect a chat model, connect a tool, describe the job. Twenty minutes and it works.

Keeping it working is a different exercise, and it is the half nobody writes about, because it only shows up after the demo. This post is mostly about the second half, with the current state of the node first, because a lot of what is written about it is out of date in a specific way that will waste your time.

What is the n8n AI Agent node?

It is a node that builds an AI agent inside an n8n workflow. You connect a chat model sub-node and at least one tool sub-node, and the agent decides which tools to call to complete a task. Tools can be any n8n integration, a sub-workflow, or an external MCP server.

n8n’s docs put it in one line: “Connect a chat model and one or more tools, and the agent decides which tools to call to complete a task.” The “at least one tool” is a hard requirement, not a suggestion.

Stop choosing an agent type. There is nothing to choose

If you have read almost any n8n agent tutorial, it opened by having you pick an agent type: Tools Agent, Conversational Agent, ReAct Agent, Plan and Execute, OpenAI Functions, SQL Agent.

That decision no longer exists. From n8n’s own docs:

The AI Agent node’s agent type setting is deprecated from n8n 1.82.0. All AI Agent nodes now work as a Tools Agent, which was the recommended and most frequently used setting. […] The version of the node (v1) that has the agent type setting will be removed from n8n 3.0.

Three consequences worth being concrete about:

  1. You cannot pick wrong, which removes a decision that consumed a lot of tutorial word count and a lot of reader anxiety.
  2. If you are on v1 of the node, update it. It stops working at n8n 3.0, and that is a hard removal, not a warning.
  3. The old SQL Agent pattern has a replacement. n8n’s guidance is to use a Postgres or MySQL tool sub-node with a current Agent node.

The legacy documentation pages still exist in n8n’s docs tree, which is why so much content still references them. They describe a setting that has been deprecated for over a year.

There is also a newer, separate thing called Agents - its own builder, distinct from workflows, available from n8n 2.34.0. It is in Preview, and n8n’s own docs say “Avoid relying on them in production workflows.” If you are reading about “n8n agents” and it does not look like a node in a workflow, that is what you are reading about.

The pieces

Chat models. Sub-nodes ship for Anthropic, OpenAI, Google Gemini, Google Vertex, AWS Bedrock, Azure OpenAI, Mistral Cloud, Cohere, DeepSeek, Groq, xAI Grok, OpenRouter, NVIDIA, MiniMax, Moonshot, Alibaba Cloud, Vercel, Lemonade, Hugging Face Inference, and Ollama.

Ollama is the interesting one if you are self-hosting, because it moves inference onto your own hardware, and with it the RAM requirement of the model itself. That is a different order of magnitude from everything else in this post and worth deciding early rather than discovering.

Memory. Simple Memory (buffer window), Memory Manager, Postgres Chat Memory, Redis Chat Memory, MongoDB Chat Memory, Motorhead, Xata, Zep. Note if you are pricing this against a managed host: we run PostgreSQL, MySQL and Redis as one-click services on the pod, so Postgres and Redis chat memory need nothing extra. MongoDB is an n8n option but not one of ours, so you would point it at a database you host elsewhere.

Simple Memory is in-process. That is fine on one instance, and it is a trap in queue mode, where the worker that handles the next message may not be the one holding the buffer. If you have scaled n8n, use Postgres or Redis chat memory. Postgres has the additional benefit of surviving a restart, which Simple Memory does not.

Tools. Any n8n integration exposed as a tool, sub-workflows as tools, and external MCP servers via the MCP Client Tool sub-node. From n8n 2.22.0 there is a one-click MCP registry in the nodes panel, initially covering Apify, Linear, monday.com, Notion and PostHog, so you can attach those without configuring a credential by hand.

n8n’s own rule for choosing between a built-in tool and an MCP server is a good one: a built-in tool when “you know which action the agent needs and want it tightly scoped”, an MCP server when “the agent needs a range of actions, or you don’t know in advance which one.” Scope down where you can. A tightly-scoped tool is a smaller failure surface and a cheaper prompt.

The four things that take an agent down

Everything above is the part that works in testing. Here is what does not survive contact with a schedule.

1. Memory, because agents are not workflows

A normal n8n workflow is a pipeline: data enters, transforms, leaves. Peak memory is roughly the biggest single payload.

An agent is a loop. It calls a model, gets a tool request, runs the tool, appends the result to context, calls the model again. Every iteration’s output stays in memory for the whole run, and the run’s length is decided by the model rather than by you. A workflow that averages 4 tool calls will occasionally do 30, and that run’s memory is not 7 times the average, it is the sum of everything the loop accumulated.

n8n does not publish a RAM figure for agents. The nearest published numbers:

So 180 MiB is the floor before you have done anything. On a 512 MB box that leaves roughly 330 MiB for an unbounded loop, which is why agents on the smallest tier fail intermittently rather than never - small runs pass, long ones get killed, and it looks like a flaky model rather than a memory ceiling.

Practical floor for an agent: 2 GB. Not because 2 GB is generous, but because the failure below it is non-deterministic and therefore expensive to debug. For general n8n sizing rather than the agent case specifically, see n8n server requirements; if it is already slow, why is n8n slow works through the causes in order before you reach for queue mode.

2. Execution data fills the disk

Every agent run stores its execution data, and agent runs are verbose: the full context of every model call and every tool result.

The one that actually matters is binary data, because it is the only one of these where n8n’s default works against you:

N8N_DEFAULT_BINARY_DATA_MODE=filesystem

Binary data defaults to memory, and a base64 image sitting in an agent’s context is memory you did not budget for. Switching it to filesystem is the single highest-value line here.

Pruning, by contrast, is already handled. n8n enables it by default, and has for a long time:

EXECUTIONS_DATA_PRUNE=true            # default: true
EXECUTIONS_DATA_MAX_AGE=336           # default: 336 hours = 14 days
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 # default: 10000

We set all three explicitly in our own image, but setting a value to its own default changes nothing at runtime; we pin them so a future upstream default change cannot surprise a running pod. If a guide tells you to “turn on execution pruning” to fix a slow n8n, it is solving a problem you do not have - why is n8n slow works through the causes that are actually real, in order.

3. The public URL, which is not an agent problem until it is

Chat triggers and webhook triggers need n8n to know its own public address. Get this wrong and the agent works perfectly in the editor and never fires in production.

N8N_WEBHOOK_URL=https://n8n.example.com
N8N_PROXY_HOPS=1

Note the name: WEBHOOK_URL is deprecated from n8n 2.35.0, replaced by N8N_WEBHOOK_URL. The old one still works with a warning, and virtually every guide written before mid-2026 uses it, so check what your compose file actually says.

4. No timeout on tool calls

An agent tool that makes an HTTP request to something slow will hold that execution as long as the remote end lets it. In queue mode that is a worker doing nothing. Set timeouts on HTTP Request tool nodes. It is a one-field change that turns “the agent stopped working overnight” into “one execution failed.”

What managed hosting does and does not do here

Being straight about this, because it is the whole reason a hosting company can write this post honestly or not.

What it does: gives the agent somewhere reliable to run. HTTPS and a stable public URL so triggers fire. Enough RAM that the loop is not fighting the ceiling. Backups so a bad workflow edit is recoverable. Certificate renewal, OS patching and the n8n upgrade treadmill handled by someone else - n8n ships multiple releases a week, so that treadmill is real.

What it does not do: make the agent good. Nothing about hosting improves your prompt, picks your tools, stops the model looping, or prevents an agent from confidently calling the wrong tool. Those are workflow problems and they are yours. Any host implying otherwise is selling you something.

The sizing question is the honest one, so: n8n on InstaPods is $7/mo flat on the Build plan, which is 2 vCPU, 2 GB RAM and 25 GB SSD. That 2 GB is the practical floor above, which is why it is the minimum plan we run n8n on rather than the $3 tier. If your agent runs local models via Ollama, none of these numbers apply and you want to be thinking in tens of gigabytes on hardware with a GPU. That is a different product from anything priced in this post, ours included.

N8N_DEFAULT_BINARY_DATA_MODE=filesystem, the prune settings and the public webhook URL are all configured at deploy on our image, so two of the four failure modes above are handled before you start and the third is a matter of picking a plan with enough RAM. The fourth, tool timeouts, is inside your workflow and no host can reach it.

On versions: we pin what we bake rather than tracking latest, so what you get depends on when we last rebuilt the image. As of 2 September 2026 that pin is 2.37.7, npm’s current release. It will drift as n8n ships, which is often, so check your own n8n --version rather than trusting this sentence - updating is one click with an automatic snapshot and rollback.