What is the n8n AI Agent and how does it work?

What is an n8n AI Agent made of?

The AI Agent node has three inputs you must connect and one optional.

Model (Chat Model). Required. The agent's brain: Gemini, GPT, Claude, a model through OpenRouter or a local one through Ollama. The model receives the instructions, the message and the list of tools, and returns either an answer or a decision to call a tool.

Instructions (System Message). The most important part of the configuration. It defines who the agent is, what format it answers in and how it should use tools. The default "you are a helpful assistant" has to go. The most common mistake I see in workflows built without n8n knowledge: the instructions describing how to work end up in the user message, and the system message stays empty. The result is hallucination and poor quality even though the same prompt works beautifully in ChatGPT. The rule is simple: the system message says how the agent works, the user message carries only the data to process.

Tools. The agent's hands. Without them the agent is a plain chat. n8n offers five kinds: another workflow as a tool, a Code Tool with a JavaScript snippet, an HTTP Request Tool, an MCP Client Tool that connects an external MCP server, and another agent as a sub-agent. Ready-made integrations such as Google Sheets or Gmail come on top.

Memory. Optional. Unnecessary in most automations, because the agent runs within a single workflow execution and does not need to remember previous ones. Needed in chats and assistants where a conversation spans many turns.

A fourth, hidden input appears when you tick "Require Specific Output Format": an Output Parser with a JSON schema. With it the agent returns validated fields instead of an essay you have to mine for columns.

Agent or plain workflow?

An agent is more expensive, slower and less predictable than a rule. Use it only where the process needs understanding or judgement: lead qualification, ticket classification, reading a document, choosing a path based on content. Where a condition is enough, the condition is cheaper, faster and predictable.

A typical example from implementations: someone wants to attach four HTTP calls to an agent as alternative paths and let the model choose. If the logic reads "check here, if it fails check there", the process is deterministic. Build it as a workflow: it costs nothing, the result is certain, and handing the decision to a model only adds non-determinism and a chance of error.

Data from the n8n AI Automation Index confirms that practice agrees. Among workflows built by AI agents only about 7% contain a language model node, down from 17% in March 2026. What grows is the deterministic part: webhooks, schedules, database syncs. The agent is one tool in the workflow, not its purpose.

How do you build a good tool for an agent?

The most flexible tool is a sub-workflow. The agent passes parameters, the sub-workflow does the heavy lifting and returns a result. A few rules decide whether the agent uses the tool correctly:

• Always return a response. Success or a readable error message, never an empty result. An agent that gets nothing does not know whether to keep trying.
• Return text, not JSON. The model understands text. Short error messages such as "service unavailable, do not retry" let the agent decide.
• The sub-workflow does the heavy work. The agent does not filter a spreadsheet with tokens. The sub-workflow filters and returns a finished result, which saves tokens and keeps deterministic logic where it belongs.
• Return a processed result, not raw data. In n8n Agents the response from an attached workflow has a fixed 4 kB limit. Above it the tool looks broken even though the sub-workflow ran fine. A whole HTML page from a scraper will not pass; a summary will.
• Give the sub-workflow an input contract. The "When Executed by Another Workflow" node lets you define fields and types. Bad data stops at the hand-off with a readable message instead of blowing up the workflow somewhere downstream.

An MCP server as a tool gives the agent a whole set of operations and lets it pick the right one itself. A single integration node is granular: you have to select a resource and an operation, so it handles one action. When the agent should work with an entire system, for example a task manager, expose an MCP server instead. n8n can build one itself with the MCP Server Trigger node.

What are n8n Agents and how do they differ from the AI Agent node?

Since August 2026 n8n has a separate Agents tab in the instance overview. The conceptual difference: a workflow is a procedure, an agent is a worker with procedures attached as tools.

	AI Agent node	n8n Agents
Defined where	inside one workflow	once, in the Agents tab
Reusability	only in that workflow	in many workflows at once
Memory	context of one execution	own memory across calls
Entry points	one place in a workflow	Slack, Telegram, Discord, Linear and calls from workflows
Skills	none	yes, loaded conditionally
Sub-agents	another agent as a tool	a dedicated tab, up to 20 in parallel

A model and instructions are enough to run one; after publishing, the agent is reachable from channels and from the "Message an Agent" node in workflows. Skills load conditionally based on phrases in their description, so the agent does not read everything on every call. Every tool has a "require approval" option: the agent must ask for consent before using it.

The simplest channel to start with is Telegram: a bot via BotFather takes minutes, no approvals or business accounts, and access should be restricted to your own user id from the start. WhatsApp requires a Meta business account and a long approval process.

One big agent or several specialised ones?

Specialised. The constraint is instruction length: the more cases a system message covers, the worse the agent performs in each of them. The architecture that scales is an orchestrator that talks to the user and delegates to sub-agents: data analytics, sales support, warehouse. A specialised sub-agent is also reusable by many orchestrators.

Sub-agents can run on a cheaper model than the orchestrator. The "smarter model as an adviser" pattern works too: the agent runs on a cheap model, and a skill tells it when to ask a more expensive one for advice, for example before a change that is hard to reverse.

How do you secure an agent?

The prompt is not a safeguard. An analytics agent with database access was told "SELECT only", but the tool technically allowed any query, including dropping a table. Three things protect you for real:

1. Least privilege. The agent gets only the tools its task needs. The most effective safeguard is not exposing a tool that enables the unwanted operation.
2. Approval on sensitive tools. The "require approval" option in n8n Agents, or a human-in-the-loop pattern in a workflow: the agent stops and waits for a person's decision in chat or a dashboard before doing anything irreversible.
3. Nothing that touches money. Price changes, transfers and data deletion stay out of the agent's reach. The internet is full of cases where an agent wiped five years of customer records.

If you expose your own MCP server from n8n, configure authentication on it. Without it the data is available to anyone who knows the address.

What does an agent in n8n cost?

n8n does not charge for tokens. That myth keeps many teams from using n8n at all. On your own server the cost is fixed regardless of the number of workflows. Only model calls are paid, at the provider's rates. A deterministic workflow without a model node costs nothing beyond the server.

Model choice: start with the cheapest Flash-class version and move up only when quality is insufficient. Models get deprecated; a quarterly review of model versions in workflows is part of maintenance, because providers retire older series and a workflow stops working overnight.

How do you test an agent without making a mess in your systems?

Three techniques from implementations:

• Disable action nodes with the D key. Data flows through the workflow, but nothing reaches external systems. Run it as many times as you like.
• Log results to a Data Table instead of digging through executions. After a few days in shadow mode an agent reviews the table and points at where the prompt needs work.
• Build evaluations. n8n has an Evaluations tab: a set of test queries run after every prompt change, with a quality score. Through n8n-mcp an agent builds that set itself.

Where to start?

With one specialised agent and one tool, built together with the team on their own instance. That format, one session, one exercise, is what I run with clients every week, and after a dozen sessions a team from finance, warehouse and sales builds its own agents without engineers.