n8n AI Agent vs Workflow: Which to Use in 2026

Since n8n added a standalone agent type in September 2026, a lot of small-business automation questions now start with the same choice: should this job be an n8n AI agent, or a classic workflow? Picking wrong costs you either way. An agent running a fixed process pays a model to rediscover steps you already know. A workflow forced to handle open-ended conversations becomes a canvas of IF nodes that still misses cases. This post explains what n8n Agents are, how they differ from workflows and from the older AI Agent node, and how I would decide between them for a small business, plus a safe setup on self-hosted n8n.

What is an n8n AI agent?

n8n announced Agents on 25 September 2026. An agent is a separate artifact in your project, next to your workflows. You give it a model, written instructions and a set of tools, and it works out the steps itself at run time. The docs describe it as a reasoning loop: the agent reads your instructions and the request, then decides whether to call a tool, search its knowledge base, hand off to a sub-agent or ask a follow-up question, and repeats until it has a final answer.

Each n8n agent can have:

• A model, from any provider you have credentials for, or n8n's Gateway credits.
• Instructions, written like a brief for a colleague: role, tone, limits and which tools to prefer.
• Tools: built-in n8n integrations set up for one action, whole workflows from the same project, custom tools defined by a JSON schema, and MCP servers.
• Channels and schedules: Slack, Telegram and Linear, or a recurring run (hourly to custom cron).
• Skills, sub-agents, knowledge files and memory. Session memory is on by default.

Agents have a draft and a published version, so you can edit and test without changing what your team is using.

How this differs from the AI Agent node

The AI Agent node you may already use inside workflows is unchanged. The difference is assembly: the new agent type ships with memory, sessions, channels, versions and approvals already connected, while the node is a component you wire up yourself on the canvas. Both exist side by side.

n8n workflow vs agent: the real difference

A workflow is a process you define in advance: every run follows the same path and fails in ways you can read in the execution log. An agent decides the path at run time. That flexibility is the point, and also the cost.

You don't have to choose one for the whole system. An agent can call workflows as tools, and a workflow can call an agent through the Message an Agent node. The real question is where to draw the line between fixed process and model judgement.

When a deterministic workflow is still the right answer

For most automation I build for small businesses, the answer is still a workflow, sometimes with one model step inside. I run self-hosted n8n on Docker with retries, error alerts and LLM steps, and the jobs that stay quiet in production have structured input and a known correct output.

Keep it a workflow when:

• Money moves or records change. Invoices, refunds, payroll exports, stock updates. You want the same input to give the same result, every time, with a log an accountant can follow.
• Data is syncing between systems. CRM to accounting, form to sheet, shop order to courier. Mapping fields is not a reasoning problem.
• Volume is high. A webhook that fires on every order should not wait on a model and burn tokens on a decision you could write as a rule.

If one step needs judgement (classifying an email, extracting fields from a PDF), put a model step inside the workflow and validate its output before anything writes to a system of record. That is the pattern I used for the WhatsApp AI agent and CRM pipeline: the model suggests, the workflow checks and writes.

When an n8n agent is worth it

An agent earns its cost when the next step depends on the answer to the last one. n8n's own examples are a support agent working through an inbound queue and an internal Slack bot answering questions about customers. Small-business versions of that:

• An internal ops assistant in Slack or Telegram that answers "where is order 1042?" or "what did this client buy last year?" by calling read-only lookup workflows.
• First-pass support triage: read a ticket, pull account context, draft a reply for a person to send.
• A morning summary on a schedule: what changed overnight in orders, tickets and leads.

None of those let the agent take an irreversible action on its own. That is deliberate.

Decision checklist

If most answers land on the workflow side, build a workflow.

• Can you draw every step on paper before it runs? Workflow.
• Is the input free text that changes shape every time? Agent.
• Does the job need back-and-forth, like a follow-up question? Agent.
• Does a wrong result cost money, data or a customer relationship? Workflow, or an agent whose risky tools need approval.
• Will it run thousands of times a day on structured events? Workflow.
• Do people want to ask it things in Slack or Telegram? Agent, calling workflows as tools.
• Is one decision inside a fixed process the only fuzzy part? Workflow with an AI step.

How to set up an n8n agent safely

Three controls matter more than the prompt.

1. Give the agent workflows, not raw access

If the agent needs to log CRM notes, don't give it a CRM node with full write credentials. Build a small workflow that takes an account ID and a note and does nothing else, then add that workflow as the tool. The agent decides when it runs. What it does stays fixed. Since n8n 2.44 (released 13 October 2026), each workflow tool input can be set individually: let the AI fill it with optional guidance, set a fixed value, or use an expression. Fixing a value such as a target pipeline or a sender address removes one more thing the model can get wrong.

MCP servers are the quickest tools to attach because the agent gets every tool on the server at once. You can exclude individual tools, and you should, for anything that writes. If you are building your own MCP server for an agent, my notes on the MCP stateless spec migration cover what changed in the protocol this year.

2. Put approvals on anything that writes

Mark a tool as sensitive and the agent pauses for Approve or Reject before it runs, then continues with your decision. n8n's own advice is to start "where the blast radius is small: scoped tools, a test channel, and approvals on any action that writes to a system of record." I would add: anything that sends a message to a customer.

3. Set a budget before you publish

Since n8n 2.43 (6 October 2026), agent settings include a monthly budget, a session spend cap and an optional alert threshold between 10 and 100 percent. Budgets only take effect when set above 0. Set one on day one.

n8n agent pricing: how executions are counted

n8n prices plans by executions, and an execution is one complete workflow run, however many steps it has. For agents, one turn (you send a message, it produces a response) is one execution. Tool calls to your workflows and to sub-agents don't count separately, and agents share the same execution quota as your workflows. A message sent from the Message an Agent node also counts as one execution.

Is n8n free? The Community Edition is free to self-host, with agents from 2.32.3. On n8n Cloud, Agents (preview) are listed on every plan, including Starter.

Running n8n agents on self-hosted n8n

The agents module loads by default from 2.32.3, and an instance owner or admin can switch it on or off under Settings > Agents. For a basic setup, where you pick the model and attach tools yourself, you don't need n8n Assistant or a sandbox. Two things do need configuration:

• Channels such as Slack, Telegram and Linear need a public, secure URL for your instance in N8N_WEBHOOK_URL. That variable exists from n8n 2.30.0, and the older WEBHOOK_URL is deprecated from 2.35.0 (it still works, with a startup warning).
• Knowledge bases on self-hosted are in Preview and need a configured sandbox (n8n recommends Daytona for production).

Here is the part of a Docker Compose .env that matters for agents behind a reverse proxy. It assumes the n8n service reads this file, as n8n's own get-n8n-compose.yml does with env_file: .env:

# Pin a release you have tested (agents need 2.32.3 or later)
N8N_VERSION=2.44.4

# Public HTTPS address of this instance, required for agent channels
N8N_WEBHOOK_URL=https://n8n.example.com/
# Behind one reverse proxy (also forward X-Forwarded-For/-Host/-Proto)
N8N_PROXY_HOPS=1

# Agents don't support queue mode yet; regular is the default
EXECUTIONS_MODE=regular

Pinning the version is the same habit as a CI/CD pipeline with a health check: agents change release by release, so upgrade on purpose and retest the published agent each time.

Where I would start

Don't migrate working workflows. Pick one internal, read-only job, such as a Slack ops assistant calling two lookup workflows, and build it as an agent with a budget and approvals on. Keep invoices, syncs and high-volume jobs as workflows, and move the line one tool at a time.