TL;DR
- Queue mode is not supported for agents yet, which rules out most scaled self-hosted instances
- One entry in N8N_ENABLED_MODULES turns it on; the other three setup steps are all optional
- The agents module carries no .ee suffix, so it is Sustainable Use code, not Enterprise
n8n has shipped Agents: a first-class object that sits alongside your workflows rather than inside one. Not a node, a new tab. You pick a model, write instructions, attach tools and skills, publish it with version history, and people reach it through Slack, Telegram or a schedule. It is in Preview, it works on self-hosted n8n from 2.32.3, and there is one sentence in the documentation that will decide whether you can use it at all today. We will get to that sentence in a moment, because most coverage has not mentioned it.
This is part eight of our n8n series. Part one covered the concepts and the licence, and this builds on both.
An agent is not a workflow, and it is not the AI Agent node
Start by separating three things that share a name. The AI Agent node is what you already use inside a workflow, and n8n is explicit that it has not changed: "The AI Agent node hasn't changed, and everything you've built with it keeps working." The Agents feature is new, and it is a different kind of object entirely. And an agent session is one conversation with one of those objects.
n8n's framing for when to reach for which is useful: agents suit work "too open-ended for a fixed workflow". If you can draw the steps, build a workflow. If the steps depend on what the request turns out to be, that is the case for an agent.
Ten things make up an agent, which is more moving parts than most write-ups list.
| Part | What it is |
|---|
| Model | The language model that reasons and responds |
| Instructions | The system prompt: role, tone, constraints |
| Tools | Workflows, custom code, n8n integrations, MCP servers |
| Web search | The model's native search, or Brave or a self-hosted SearXNG as fallback |
| Skills | Reusable bundles of instructions plus the tools for one task |
| Knowledge base | Searchable uploaded files: csv, pdf, markdown, txt |
| Memory | Session memory for the current conversation, episodic for earlier ones |
| Sub-agents | Other published agents this one can delegate to |
| Channels | Slack, Telegram, Linear |
| Schedules | Recurring runs, once published |
The last two only take effect when you publish. Everything else is live while you are building. Publishing takes a snapshot, so the running agent does not change under your feet while you edit the draft, and every publish adds a restorable version.
One hard dependency worth knowing before you plan around it: session memory is on by default and needs no setup, but episodic memory requires an OpenAI credential, regardless of which model actually runs the agent. If you are running everything through a local model, episodic recall still reaches for OpenAI.
The skill-versus-tool distinction is the one most coverage skips, and it matters because it changes how you structure an agent that does more than one job.
A tool is one capability: a workflow, a code block, an integration, an MCP server. A skill is a named, described bundle that packages instructions together with the subset of tools that task needs. The agent picks the skill by reading its description against the incoming request. So a skill contains tools; a tool never contains a skill. If your agent handles several distinct tasks each with its own steps, skills are how you keep those from bleeding into one another in a single enormous system prompt.
Sub-agents go a step further and hand work to another published agent, with a configurable cap on how many run in parallel. For sensitive operations you can require approval on a specific tool, and the agent pauses and asks before running it. That per-tool approval is the documented safety mechanism inside agents.
Turning it on when you self-host
Here is the part Cloud users never see. On self-hosted n8n (part two covers getting one running), Agents is a module you enable, and it is worth knowing that N8N_ENABLED_MODULES is not documented on any general environment variable page. It lives in one section of the n8n Assistant setup page, which is a strange place for the switch that turns on a flagship feature.
N8N_ENABLED_MODULES=instance-ai,agents
N8N_AGENTS_AI_SANDBOX_ENABLED=true
N8N_AGENTS_AI_SANDBOX_PROVIDER=daytona
WEBHOOK_URL=https://your-public-url
It is a comma-separated list, not a boolean. And three of those four things are optional, which the docs are clearer about than the blog posts are.
| Leave it out | What you lose |
|---|
agents in the module list | Everything. This is the gate. |
instance-ai | Only AI-assisted scaffolding. Building manually is, in n8n's words, "all you need to build and run agents" |
| The Daytona sandbox | The knowledge base only. "Without it, the rest of the agent still works" |
A public WEBHOOK_URL | Channels. Slack, Telegram and Linear all need to reach you |
So the minimum viable setup is one entry in one environment variable. You can have a working agent with tools and memory without Daytona, without the Assistant and without exposing anything publicly, and that is the configuration most people reading this should start from.
On Daytona specifically: it needs an account and an API key either way, and n8n documents both its hosted endpoint and a self-hosted Daytona URL, recommending the hosted one for production. We have not verified what it costs, so budget for an unknown rather than assuming free.
The limitation that decides it for you
Now the sentence. Straight from the agents documentation:
"Queue mode isn't supported for agents yet, and connecting channels (such as Telegram) can fail. Run agents in regular mode for now."
Queue mode is how you scale self-hosted n8n. It is the standard production topology, it is available even on the Community edition, and if you are running n8n for anything that matters you are probably running it. Agents do not work there yet.
That makes this, for most serious self-hosters, a feature you evaluate on a second instance rather than enable on your production one. It is not a small caveat and it is not in the launch post.
Two more worth knowing. Channel connection is admitted as fragile in that same sentence. And if you route model calls through an OpenAI-compatible gateway such as Portkey, OpenRouter or a LiteLLM proxy, there is an open issue where the agent builder strips the provider prefix from the model id and silently drops custom credential headers, which breaks the connection outright.
What it costs
Three separate meters, and nobody lays them out together.
| Meter | Pays for | Who sees it |
|---|
| Executions | One per agent turn, shared with your workflow quota | Everyone |
| Assistant credits | Your conversations with n8n Assistant while building | Cloud Starter and Pro only |
| Gateway credits or your own key | The model the agent actually runs on | Everyone |
The detail that makes the first row generous: calls to workflow tools and to sub-agents do not count separately. One turn is one execution no matter how much the agent does inside it, which is a meaningfully better deal than it first looks.
If you self-host, Assistant credits never apply. The Assistant runs on your own provider account and bills you directly.
Is it open source
No, and we covered why in part one: n8n is source-available under the Sustainable Use Licence v1.0, which n8n itself calls fair-code. In their words, "we do not call ourselves open source". GitHub's API reports the licence as NOASSERTION, which is what that looks like from the outside.
Part one teaches readers to check whether a feature sits in .ee paths, since those fall outside that licence and need a commercial Enterprise key. So we checked. The agents module lives at packages/cli/src/modules/agents/, with no .ee suffix, while its siblings ldap.ee, external-secrets.ee, log-streaming.ee and instance-reporting.ee all carry one. Agents is Sustainable Use code, not Enterprise code. That is consistent with it running on self-hosted Community, and it means the self-hosted Enterprise exclusion is a rollout decision rather than a licensing one.
There is one licence clause that bites this feature specifically, and anyone planning to build a product on it should read it twice. The Community licence forbids you to "allow external end users to build or configure their own workflows through your product, whether via a custom UI, our API, MCP, or an AI agent acting on the user's behalf". Letting your own customers direct an n8n agent that authors automations for them is outside the licence. Triggering pre-built workflows for them is fine.
What changed, version by version
The version story is messier than a changelog entry suggests, and it is worth getting right before you pin an image.
| Version | Date | What it means |
|---|
| 2.32.3 | 2026-07-23 | Documented self-hosting floor. Note it was a prerelease; 2.32.5 on 2026-07-24 was the first stable at or above it |
| 2.40 | 2026-09-15, announced 09-21 | The public launch |
| 2.41.5 | 2026-10-01 | Current stable. This is what latest installs |
| 2.42.2 | 2026-10-01 | Current beta, where the newest agent builder polish lands |
The floor predates the launch by two months, so Agents was shipping behind a module flag long before anyone announced it. If you read elsewhere that 2.42 is the current release, that is the beta channel; n8n publishes both and the npm latest tag points at 2.41.5.
One unrelated deadline worth noting while you are in the release notes: npm installs stop working with n8n 3.0 in October. If you installed with npm rather than Docker, that is a migration with a date on it.
Two places the sources disagree
Worth flagging rather than resolving, because you will see both.
On channels, the reference documentation lists exactly three: Slack, Telegram and Linear. The changelog and the launch blog both also list Discord. We are going with the documentation, since that is the page maintained per release, but do not be surprised either way.
On Enterprise, the agents docs say plainly that agents "aren't available on self-hosted Enterprise yet", while the changelog says "On Enterprise, agents are in Preview". The most likely reading is that the changelog means Cloud Enterprise, but n8n does not say so. If you are on Enterprise, ask rather than assume.
Should you turn it on
Turn it on if you run n8n in regular mode and want to try something genuinely new, or if you have a job that is too open-ended to draw as a workflow and you have been forcing it into one anyway. The minimum setup is one environment variable, which is a low price for finding out.
Wait if you run queue mode, which is most people with a production instance. Wait if you need Enterprise. Wait if your model calls go through a gateway, until that issue closes. And whatever you do, take n8n's own advice from the changelog: "Test before you publish, and require approval on tools that write to your systems."
For the workflows you have already built from this series, nothing changes. The markdown chatbot and its pgvector RAG upgrade both use the AI Agent node, which is untouched. Agents is a second way to build, not a replacement for the first.
Sources and further reading
Ten minutes: add agents to N8N_ENABLED_MODULES on a test instance, restart, open the Agents tab and build one with a single tool and no channel. You will know within one conversation whether the object model fits how you think about your automations, and you will have spent nothing but a restart to find out.
Tested on: not independently tested. Every figure here is published by n8n in its own documentation, changelog or licence; the version and release-channel data come from the GitHub and npm APIs. Our own n8n instance was not upgraded and was not used as evidence for anything in this article. The module path check was made against the public source tree.
Date checked: 2026-10-01
