Quick answer: n8n has a built-in AI Agent node that turns a language model into an agent — something that can reason about a request and call tools (other nodes, APIs, your data) to actually do things, not just chat. You connect three things to it: a chat model (OpenAI, Anthropic Claude, or another), one or more tools it's allowed to use, and optionally memory so it remembers the conversation. Add a clear system prompt defining its job and limits, and you have a working agent inside a workflow. Here's how to build one properly — and safely.
(New to the concept? Start with what AI agents are for the business framing; this guide is the hands-on build.)
The anatomy of an n8n AI agent
The AI Agent node is the orchestrator. On its own it can talk; its power comes from what you attach to it, using the small connection ports on the node:
- Chat Model: the brain — the LLM that reasons. Connect an OpenAI, Anthropic (Claude), Google, or other model node. This is where you bring your own API key (BYOK), so you pay the provider directly.
- Tools: the hands — the things the agent can actually do. Each tool is a capability: search the web, look up a record in your database, send an email, call an API, run a sub-workflow. The agent decides which tools to use and when.
- Memory: the short-term recall — connect a memory node so the agent remembers earlier turns in a conversation (essential for chatbots, optional for one-shot tasks).
This structure is why an agent is different from a simple "call ChatGPT" node: the agent can look at a request, decide it needs to check your CRM, call that tool, read the result, decide it now needs to send an email, call that tool, and report back — a multi-step loop of reasoning and action, all inside one n8n node.
Step 1 — Connect a chat model
Add the AI Agent node, then attach a chat model to its Chat Model port. For most business tasks a capable frontier model (GPT or Claude) is the right default; for cost-sensitive or data-sensitive workloads you can point it at a self-hosted open-source model via Ollama. Keep your own provider API key in n8n's credentials so usage bills to you at published rates — never a marked-up middleman. Model choice matters less than people think for well-scoped tasks; start with a strong general model and optimize later.
Step 2 — Give it tools
Tools are what make an agent useful. In n8n you attach tool nodes to the agent's Tool port, and each one gets a name and description that tells the agent when to use it. Good starting tools for a business agent:
- A database/CRM lookup (e.g., an HTTP Request or NocoDB/Airtable tool) so it can check customer records before answering.
- A search tool for information it doesn't have.
- An action tool — send an email, create a ticket, book a slot — via the relevant node.
- A sub-workflow tool — wrap an existing n8n workflow as a tool the agent can call, which is how you give it complex, reusable capabilities.
Describe each tool clearly — the description is how the agent decides whether to use it. Vague descriptions lead to the agent ignoring a tool or misusing it; precise ones ("Look up a customer's order history by their email") lead to reliable behavior.
Step 3 — Write the system prompt
The system prompt defines the agent's role, its boundaries, and how it should behave. This is where you do most of your "programming" of an agent. A good system prompt states: who the agent is and its goal, which tools it has and when to use them, what it must never do, and how to handle uncertainty (e.g., "if you're not sure, ask rather than guess"). Be explicit about limits — an agent with tools that can send messages or change records needs clear rules about when it may act versus when it must escalate to a human.
// Example system prompt skeleton:
You are a support assistant for [Company]. Your job is to answer
customer questions and, when appropriate, look up their account.
Tools:
- "lookup_customer": use to fetch a customer's details by email.
- "create_ticket": use ONLY when the issue needs a human; never for
routine questions.
Rules:
- Never share another customer's data.
- If you are unsure or the request involves a refund, do NOT act —
create a ticket for a human instead.
- Be concise and friendly.Step 4 — Keep it safe (the part that matters most)
An agent with tools can take real actions, so guardrails aren't optional. The patterns we insist on for any client agent: human-in-the-loop for anything irreversible — money, contracts, external messages of consequence — where the agent proposes and a person approves; scoped tools so the agent literally cannot do things outside its remit (don't give a support agent a "delete customer" tool); validation on tool outputs before acting on them; and logging of every action so you can audit what it did. Start a new agent supervised, watch what it does on real inputs, and widen its autonomy only as it earns trust. An agent is powerful precisely because it acts — which is exactly why its ability to act must be bounded.
A real example: a triage agent
A concrete build we deploy: an inbound-support triage agent. A message arrives (webhook) → the AI Agent node reads it, uses a lookup tool to pull the customer's account, and classifies the request → routine questions it answers directly and logs; anything involving billing, a complaint, or a refund it does not handle, instead using a "create_ticket" tool to route to a human with a summary and the account context attached. The result: the agent clears the high-volume routine load 24/7, humans get only the cases that need them, pre-contextualized. That's an agent doing real work inside guardrails — the whole point.
Common mistakes when building n8n agents
Most agent projects that disappoint fail for predictable reasons. Vague tool descriptions: the agent decides which tool to use based on its description, so "search" is useless where "search the customer database by email to find their order history" is reliable — invest in precise descriptions. No guardrails: giving an agent powerful tools without human-approval gates or scope limits is how it does something you didn't intend; bound its power deliberately. Over-scoping: trying to build one agent that does everything produces an unreliable generalist — narrow, single-purpose agents work far better. Skipping memory where it's needed: a chatbot agent without memory forgets the conversation each turn; add a memory node for anything conversational. No logging: if you can't see what the agent did and why, you can't trust or improve it — log every action.
The meta-lesson: an agent is only as good as its scope, its tools' descriptions, and its guardrails. Teams that treat those three as the real work — rather than assuming a powerful model alone makes a good agent — ship agents that actually get used. The model is the easy part; the engineering around it is where reliability lives.
How is an n8n AI agent different from just calling ChatGPT in a workflow?
A plain LLM node generates text from a prompt — one input, one output. An AI Agent node can reason and act in a loop: it decides it needs information, calls a tool to get it, reads the result, decides on the next action, calls another tool, and so on until the goal is met. That tool-using, multi-step autonomy is what makes it an agent rather than a text generator.
Can an n8n agent use my company's data?
Yes — that's what tools are for. You give the agent a tool that queries your database, CRM, or knowledge base (via the appropriate node or an HTTP Request), and it can look up your actual data to answer questions or make decisions. Keep that data on infrastructure you control (self-hosted n8n plus your own database) so sensitive information never leaves your environment.
FAQ
What is the AI Agent node in n8n?
It's a node that turns a language model into an agent — it can reason about a request and call tools (other nodes, APIs, your data) to take multi-step actions, not just generate text. You connect a chat model, tools, and optional memory to it, and it decides which tools to use to accomplish the goal you've defined in its system prompt.
Which AI model should I use for an n8n agent?
For most business tasks, start with a strong frontier model (GPT or Claude) via your own API key. Use a self-hosted open-source model (through Ollama) when data sensitivity or per-token cost demands it. Model choice matters less than a clear system prompt and well-described tools for well-scoped tasks — get those right first, optimize the model later.
How do I stop an n8n agent from doing something dangerous?
Scope its tools so it physically can't (don't give it destructive capabilities), require human approval for irreversible actions (money, contracts, external messages), validate tool outputs before acting, and log everything. Write explicit "never do X; escalate instead" rules into the system prompt. Start supervised and widen autonomy only as it proves reliable.
Do I need to know how to code to build an n8n agent?
No — the AI Agent node is configured visually: you attach a model, tools, and memory, and write the system prompt in plain language. Some advanced tools (custom API calls, sub-workflows) benefit from technical comfort, but a useful agent can be built entirely in n8n's visual editor without writing code.
Can I run an n8n AI agent on the free self-hosted version?
Yes — the AI Agent node works on self-hosted n8n (free Community Edition). You'll pay your AI model provider for usage (via your own key), but the n8n platform itself is free to self-host. Pairing self-hosted n8n with a pay-as-you-go model key is one of the most cost-effective ways to run production AI agents.
Want an AI agent built for your business — safely, and owned by you? That's our core work; get a free audit, or read about our AI agent development. Related: n8n error handling and what AI agents are.