Most teams don't need to hand-write agent code to get real work out of an LLM. If you already run n8n for automation, you can stand up a working, tool-using AI agent in a handful of nodes: drop an AI Agent node on the canvas, connect a chat model, attach at least one tool, and feed it with a Chat Trigger. The agent reads each message, decides which tools to call, and loops until the job is done. This guide walks the exact build, the settings that trip people up, and how to move the agent off the test canvas into something you can trust.
Key Takeaways
- Short answer: Add an AI Agent node, connect a Chat Model and at least one tool sub-node, and trigger it with "When Chat Message Received." That is the minimum working agent.
- Since n8n version 1.82.0, every AI Agent node runs as a Tools Agent. The old agent-type dropdown is gone, so there's one path to learn.
- A chat model and one tool are required. Memory is optional, but you need it the moment the agent has to remember what was said two messages ago.
- Tools are ordinary n8n nodes (HTTP Request, Call n8n Workflow, app nodes, the MCP Client Tool). The model fills their parameters through the
$fromAI()function. - Simple Memory holds context only inside one session and fails under queue mode. For production, back memory with Postgres or Redis.
What Do You Need Before You Start?
Three things, and none of them is a codebase.
- An n8n instance, self-hosted or Cloud, on version 1.82.0 or newer so you get the single Tools Agent behavior described here.
- Credentials for a chat model that supports tool calling: OpenAI, Anthropic, Groq, Mistral Cloud, or Azure OpenAI. To keep everything local, run a tool-capable model behind an Ollama chat model instead.
- At least one thing for the agent to actually do: an API endpoint to hit, an existing n8n sub-workflow, or an app node like Airtable or Gmail.
How to Build a Tool-Using Agent in n8n, Step by Step
Finish this section and you have a running agent. Everything after it is hardening and depth.
- Create the workflow and add the trigger. Start a new workflow, click the add-node button, search "Chat," and pick When Chat Message Received. This Chat Trigger opens a live chat panel where you can talk to the agent and watch it reason.
- Add the AI Agent node. Connect the trigger's main output into it. Leave Source for Prompt (User Message) set to Connected Chat Trigger Node so the agent reads the
chatInputfield automatically. - Connect a chat model. Click the + Chat Model connector under the agent, choose your provider's chat model node (for example OpenAI Chat Model), select the credential, and pick a model that supports tool calling.
- Write the system message. Open the agent's Options and add a System Message. Keep it concrete about scope and failure behavior:
You are a support assistant for Acme. Answer only using the tools provided. If a tool returns nothing, say so plainly and ask one clarifying question. Never invent order numbers, prices, or dates. - Attach at least one tool. Click the + Tool connector and add, say, an HTTP Request tool. Fill in the Description so the model knows when to reach for it, then let the model supply parameters with
$fromAI():
The agent will not call a tool it can't understand, so the Description does real work.{{ $fromAI('city', 'The city to look up weather for', 'string') }} - Add memory (optional but usually wanted). Click the + Memory connector and add Simple Memory. Set a Session Key and a Context Window Length (the number of previous interactions to keep). Without this, every message starts cold.
- Test in the chat panel. Click Chat in the trigger, send a message that should force a tool call, and watch the execution. Open the agent's output to confirm which tool ran and what it returned.
Which Chat Model and Tools Should You Wire In?
The model is the reasoning engine, so it has to support tool calling. The Tools Agent works with OpenAI, Groq, Mistral Cloud, Anthropic, and Azure OpenAI chat models out of the box, plus local models through Ollama. If an agent silently refuses to use tools, a model without proper tool-calling support is the first thing to rule out.
Tools are where n8n pulls ahead of a raw agent framework. Any of hundreds of n8n nodes can act as a tool: an HTTP Request for arbitrary APIs, a Code tool for quick logic, an app node for services like Slack or Notion, and the Call n8n Workflow Tool to run an entire sub-workflow and hand its output back to the agent. That last one lets you keep messy business logic in a normal workflow and expose it to the agent as a single clean action.
How Does the Agent Fill In Tool Parameters?
Through the $fromAI() function. When you click "Let the model define this parameter" on a tool field, n8n drops in a $fromAI() expression naming the argument, a description, and a type. The model reads that description and generates the value at runtime, which means one well-described field beats a paragraph of prompt instructions. You can mix it with static values too, so part of a request is fixed and part is model-driven.
Where Should Memory Live in Production?
Simple Memory is fine on the test canvas and wrong for anything real. It lives in the workflow process, so it doesn't persist between sessions, and it breaks outright in queue mode because n8n can't promise the next message hits the same worker. Swap it for a database-backed memory before you ship.
| Memory option | Persists across sessions | Safe in queue mode | Use when |
|---|---|---|---|
| Simple Memory (Window Buffer) | No | No | Local testing on a single worker |
| Postgres Chat Memory | Yes | Yes | Production with durable, queryable history |
| Redis Chat Memory | Yes | Yes | High-throughput chat where speed matters more than long retention |
What Are the Common Errors, and How Do You Fix Them?
- "A Chat Model sub-node must be connected." The agent ran without a model. Click the + Chat Model connector and attach one.
- "No prompt specified." The agent expected the prompt from a previous node but didn't get it. Either confirm the Chat Trigger feeds the agent, or switch Source for Prompt to Define below and build the text yourself.
- "400 Invalid value for 'content': expected a string, got null." Your Prompt resolved to null. Check that any expression in the Text field references a real field, or strip null values from the input's
chatInput. - "Error in sub-node Simple Memory." Usually a stale node version from a copied template. Delete the Simple Memory node and re-add it to force the current version.
- The agent ignores a tool it should use. The tool Description is too vague. Rewrite it to state exactly when the tool applies and what input it expects.
What Should You Do Next?
Once the agent answers correctly in the chat panel, move it toward production. Replace Simple Memory with a Postgres or Redis memory node, activate the workflow so the Chat Trigger serves a hosted or embeddable chat endpoint, and add guardrails around any tool that writes data.
Two upgrades pay off quickly. Give the agent access to remote tools with the MCP Client Tool so it can call an MCP server you build in Python. And when the agent's control flow outgrows a single node, compare it against a code-first design like a stateful LangGraph agent to decide what belongs in n8n and what belongs in code. Since the n8n agent wraps LangChain primitives, the mental model carries over cleanly.