How to build an AI agent with n8n: from prototype to production
What is the difference between an AI agent and an n8n workflow?
An n8n workflow runs a fixed sequence of steps; an AI agent decides for itself which tool to call, in what order, and when to stop. In practice, the workflow follows a path you draw: if A, then B, then C. You decide every branch in advance. It is predictable, it is testable, and for many needs it is exactly what you want.
An AI agent is different: it decides what to do based on the input, then it acts. Instead of following a path you coded, it has a goal, a language model that reasons, and a toolbox. The agent chooses which tool to call, in what order, and when to stop.
In n8n, this difference takes shape through the AI Agent node. This node is based on LangChain (the n8n-nodes-langchain.agent integration). Since version 1.82.0, it works as a single Tools Agent that implements LangChain tool calling: the model receives the list of available tools and decides for itself which ones to call.
The practical consequence is important. A fixed workflow fails predictably: you know where it breaks. An agent can fail creatively: it can pick the wrong tool, loop, or invent an answer. That is why an agent demands more guardrails than a workflow, especially in production. If your need fits into a few deterministic branches, a simple workflow will be more robust and cheaper. Reserve the agent for cases where the decision itself is the added value.
The 4 prerequisites for an n8n AI agent: instance, model, tool, data
Four building blocks are enough for a first working agent: an n8n instance, a language model (Chat Model), at least one tool (Tool) and context data.
1. An n8n instance. Two options. Either self-hosting: officially via Docker (recommended by n8n) or via npm (Node.js 20.19 to 24.x). Without a license key, you run on the free Community edition. Or n8n Cloud: no infrastructure to manage, but billing per execution (see below).
2. A language model (Chat Model). The agent needs a brain. n8n connects to several providers via Chat Model sub-nodes: OpenAI, Anthropic, Groq, Mistral, Azure OpenAI, among others. You supply your own API key for the chosen provider; that cost is separate from n8n.
3. At least one tool (Tool). This is what lets the agent act, not just chat. n8n offers more than 100 integrations usable as tools: HTTP request, code execution, Slack, Google Workspace, and many others. The documentation is clear on this point: you must connect at least one tool to an AI Agent node.
4. Data and context. An agent without access to the right data produces generic answers. Depending on your case, this can be a knowledge base, a business API, a folder of documents, or a system via MCP (Model Context Protocol), which n8n supports both as a server and as a client.
For a first prototype, the Community edition locally and a model API key are more than enough. You have nothing to pay n8n as long as you stay self-hosted.
Building the agent, step by step
Here is the full sequence, from the trigger to production. Each step is detailed, but the guiding idea stays the same: never skip the checkpoints.
- Define the trigger and the input. Choose how the agent is invoked. The
Chat Triggersuits a multi-turn conversation. For an agent that runs without a human, use another trigger: webhook, schedule, an incoming email or file. Define precisely the expected input format. - Place the AI Agent node and its model. Add the
AI Agentnode, connect a Chat Model sub-node (OpenAI, Anthropic, Mistral, etc.), and write a clear system instruction: role, scope, what the agent must not do. A good system instruction is your first guardrail. - Wire the tools. Connect at least one Tool sub-node. Start minimal: one or two well-described tools beat ten vague ones. The quality of each tool description determines whether the agent uses it correctly.
- Add memory (if conversation). For a continuous conversation, attach a Memory sub-node. An important point verified in the docs: memory does not persist between sessions. If you need durable persistence, plan for external storage. n8n recommends connecting the same Memory sub-node to the Chat Trigger and to the agent, for a single source of truth.
- Insert checkpoints and validation. This is the step most tutorials skip. Before the agent triggers a consequential action (sending an email, writing to a database, publishing), add a check: format validation, business rule, or human approval. Log every decision the agent makes so you can audit it.
- Test on real cases. Do not validate on a "hello world". Gather real inputs, including edge cases and malicious or malformed inputs. Watch what the agent decides, not just what it answers. Adjust the instructions and tool descriptions until the behavior is stable.
- Control costs and loops. Set an iteration limit to keep the agent from looping indefinitely. Monitor the number of model calls: an agent can multiply LLM calls without you seeing it. Define a budget and alert when it is exceeded.
- Move to production. Activate the workflow, set up monitoring (executions, errors, latency), and keep the decision logs. Start with a narrow scope and human supervision, then expand autonomy as reliability is confirmed.
The golden rule: an agent goes to production the day its behavior is predictable on real cases, not the day the demo works.
Common mistakes (and what actually breaks)
Most agents fail for the same reasons. Knowing them in advance saves weeks.
- Hallucination. The model invents a piece of data, an identifier, a reference. Without output validation, the agent acts on something false. Defense: check outputs against a source of truth before any action.
- Loops. The agent calls the same tool again without progressing, or chains reasoning endlessly. Defense: a strict iteration limit and an explicit exit condition.
- Runaway costs. Each agent turn can trigger several model calls. At volume, the LLM provider bill climbs fast. Defense: cap iterations, choose a model suited to the task, monitor consumption.
- No guardrails. Giving an agent write access without validation is letting it act blind. Defense: checkpoints before every consequential action, and human approval on sensitive actions.
- No testing on real cases. An agent that works on three polished examples breaks on the fourth real input. Defense: test on real data, edge cases included, before going to production.
- Too many tools, too soon. The more tools the agent has, the more it can pick the wrong one. Start minimal, add as needed.
None of these mistakes is inevitable. They disappear when you treat the agent as a system to make reliable, not as a demo to show off.
A concrete example in production
To illustrate what "to production" really means, here is a real case: Opposio (opposio.com), an online service for contesting French traffic fines. Behind the interface, a chain of agents processes each case.
The principle follows exactly the logic described above. The agent reads the received document, analyzes the possible grounds for contesting, decides on the relevant strategy, produces the appeal letter, then sends it to the right place. It is not a fixed workflow: with each case, the content and the grounds change, so the agent must reason about the specific case.
What sets a production system apart from a prototype is control at every step. Reading verified, analysis validated, decision constrained by business rules, letter produced then checked before any sending. The agent never takes a consequential action without a validation point preceding it. It is this discipline, not the sophistication of the model, that makes the service reliable.
The lesson generalizes to other domains (processing documents at scale, monitoring, takedown requests, content production): the value of an agent in production depends less on its ability to impress than on its ability to never go off the rails on a real case.
Do it yourself or delegate?
Let us be honest: you can do it yourself. n8n is designed for it. The Community edition is free and self-hostable, the visual interface reduces the need for code, and the documentation covers the essentials. For an internal agent, a well-defined use case, or simply to learn, building it yourself is the right path.
The question changes when production reliability and time become critical. Building a "hello world" takes an afternoon. Building an agent that does not break on real cases, that respects a budget, that logs its decisions and resists malicious inputs takes far more, and requires the experience of the mistakes described above.
Delegating makes sense when: the agent touches consequential actions (customers, money, sensitive data), when volume makes costs and loops dangerous, or when you do not have the time to iterate on the guardrails. That is precisely the work of Going for Growth (Fabien Cavanna), a sole operator based in France: self-hostable n8n systems, with a single person responsible, designed to run in production, not to look good in a demo. Systems that run, not promises.
Whatever your choice, the rule stays the same: an AI agent is only ready when it is predictable on real cases. Opposio is the illustration, and the method is reproducible.