automation Archives - KevinAmayi

Photo by Matheus Bertelli on Pexels How to Build an n8n AI Agent: Step-by-Step Tutorial By Kevin Amayi · May 7, 2026 · 11 min read Quick answer An n8n AI agent uses an LLM to decide which tools to call based on user input — dynamically, rather than following a fixed workflow sequence. To build one: add a Chat Trigger, connect an AI Agent node with a system prompt and an LLM, define one or more tools (HTTP Request, Code, or another workflow), and optionally add memory for conversation history. This guide covers each component, what goes wrong at each step, and when to use a regular workflow instead. Contents AI Agent vs Regular Workflow: Which to Use Prerequisites Step-by-Step: Building Your First n8n AI Agent Adding Memory to Your Agent Tools: Teaching Your Agent What It Can Do Know Your Agent When NOT to Use an n8n AI Agent Conclusion Frequently Asked Questions I had set up an n8n AI agent with two tools — one to query a product database by SKU, another to check order status by ID. First test: the agent read the message, selected the order status tool, passed the right ID, and returned the correct answer. I sent it a product question next. Same result — right tool, right output. I ran both again, not because I doubted the results, but because both working correctly on the first try felt like it warranted verification. Learning how to build an n8n AI agent that performs that consistently comes down to three things: a specific system prompt, unambiguous tool descriptions, and an LLM capable enough to make reliable decisions. This guide covers all three, plus memory, common failure modes, and the cases where you're better off using a regular workflow instead. AI Agent vs Regular Workflow: Which to Use An n8n AI agent is not a replacement for a regular workflow. They solve different problems. Factor n8n AI Agent Regular n8n Workflow Execution order Decided by LLM at runtime Fixed — you define every step Input type Natural language, open-ended Structured — webhook payload, form data Output predictability Variable — LLM decides format Consistent — you control every output Tool selection Dynamic based on user's message Fixed — same nodes every time Best for Conversational, context-dependent tasks Deterministic automation, scheduled jobs Failure mode Wrong tool selection, hallucinated data Node errors, data mapping issues The decision is simpler than it sounds: if the user's input can vary and the right response depends on understanding what they asked, use an agent. If the same steps always happen in the same order regardless of input, use a regular workflow. Both approaches are covered in the n8n automation workflow tutorial — agents are one tool in the same system, not a separate product. Prerequisites Before building an n8n AI agent, you need: n8n running — locally via npm, via Docker, or on n8n Cloud. If you haven't set it up yet, the n8n tutorial for beginners covers installation in about 10 minutes. An OpenAI API key — or credentials for another supported LLM (Anthropic, Google, Mistral). OpenAI's GPT-4o is the most reliable for tool selection; if you're using a smaller model, expect more tool-calling errors. Something for the agent to do — at least one tool or API endpoint the agent can call. An agent with no tools is just a chat interface to an LLM, which n8n does poorly compared to calling the API directly. n8n AI agent requirements The AI Agent node requires n8n version 1.19.0 or later. If you're on an older version and the AI Agent node doesn't appear in the node search, update n8n first. Check your version at the bottom of the n8n editor sidebar. Step-by-Step: Building Your First n8n AI Agent This builds a product support agent with two tools: product lookup and order status check. By the end, you'll have a working agent you can test in n8n's built-in chat interface. Step 1: Add a Chat Trigger node Open n8n → New Workflow → click the + button → search "Chat Trigger" → add the node. The Chat Trigger creates a simple web-based chat interface at a generated URL. For production, you'll replace this with a webhook or embed the chat interface in your application — but for building and testing, the built-in interface is the fastest way to iterate. Step 2: Add the AI Agent node Click + after the Chat Trigger → search "AI Agent" → select the Agent node. This is the node that handles the LLM loop: receives user input, decides which tool to call, executes the tool, passes the result back to the LLM, and generates a final response. Do not confuse it with the "LLM Chain" node — that node runs a single LLM call without tool support. Step 3: Connect an LLM In the AI Agent node, click Chat Model → Add credential → OpenAI → enter your API key. Select the model. GPT-4o handles multi-tool decisions reliably. GPT-3.5 Turbo is cheaper but noticeably less consistent when choosing between similar tools. (The cost savings become less interesting the first time a user gets the wrong answer because the model called the product lookup instead of the order status tool.) Step 4: Write a system prompt In the AI Agent node, find the System Message field. This is where you tell the agent what it is and how to behave. Be specific: You are a product support assistant for Acme Store. You have two tools: - get_product_info: Use this when the user asks about a product, its price, description, or availability. Requires a product SKU. - get_order_status: Use this when the user mentions an order number or asks about a delivery. Requires an order ID. Rules: - Always call the appropriate tool before answering. Never answer from memory or make up information. - If the user does not provide a required identifier (SKU or order ID), ask for it before calling any tool. - Keep responses concise and helpful. The specificity matters. A vague system prompt ("You are a helpful assistant") produces a vague agent that sometimes answers from its training data instead of calling your tools. Name each tool, describe when to use it, and state the rules explicitly. Step 5: Add an HTTP Request tool In the AI Agent node, click Add Tool → HTTP Request Tool. Configure: Name: get_product_info (match exactly what you wrote in the system prompt) Description: "Retrieves product details including name, price, and availability for a given product SKU" URL: your product API endpoint Method: GET Add the second tool the same way for order status. The description field is read by the LLM — write it as a clear sentence describing what the tool returns and when to call it. Step 6: Test in the chat interface Click Test workflow. n8n opens the chat interface. Send: "What's the status of order #10294?" The agent should call the order status tool and return the result. Send a product question next. Both should work in one pass. If either fails, check the execution log — n8n shows exactly which tool the agent called and what response it received. Adding Memory to Your Agent Photo by Christina Morillo on Pexels By default, n8n AI agents have no memory. Each message is a fresh conversation — the agent doesn't know what was said before. For a support agent, this means users have to repeat their order number every message. Adding memory fixes that. Memory type Persists across sessions? Requires external storage? Best for Window Buffer Memory No — resets when conversation ends No Single-session chat, quick setup Redis Chat Memory Yes Yes — Redis instance Multi-session apps, high traffic Postgres Chat Memory Yes Yes — Postgres database Auditing, long-term history, analytics Zep Memory Yes Yes — Zep server Long conversations, automatic summarization To add memory: in the AI Agent node, click Memory → select a type. For most builds, start with Window Buffer Memory and a window size of 10. This keeps the last 10 messages in context — enough for most support conversations — and requires no additional infrastructure. Switch to Redis or Postgres when you need history to survive a page refresh or a return visit. The n8n memory documentation covers the configuration options for each type, including how to scope memory to individual users using session IDs — relevant if multiple users share the same agent. Tools: Teaching Your Agent What It Can Do The tools you define determine what the agent can actually do. An agent with good tools and a clear system prompt is reliable. An agent with vague tool descriptions will misfire on tool selection — calling the wrong one or skipping one entirely. HTTP Request Tool Calls any REST API. This is the most commonly used tool type — most integrations are REST APIs, and you can configure authentication, query parameters, and request body directly in the tool configuration. The agent passes the required parameters; you define which parameters the agent can set. Code Tool Runs JavaScript or Python inline as a tool. Use this for transformations, calculations, or logic that doesn't map to a REST API. The code receives the parameters the LLM provides and returns a result the LLM uses in its response. n8n Workflow Tool Calls another n8n workflow as a tool. Useful when the tool's logic is complex enough to deserve its own workflow — for example, a multi-step data aggregation that fetches from three sources, merges the results, and applies business logic. Keeps the agent workflow clean while handling complexity in a separate, testable workflow. The one rule for tool descriptions Write the tool description as a sentence that tells the LLM when to call the tool and what it returns. "Gets order information" is too vague. "Retrieves the current shipping status and estimated delivery date for a given order ID" tells the model exactly what it gets and when it's the right choice. The description is the LLM's only guide to tool selection. For complex agents with many tools, consider grouping related tools under a single workflow tool rather than attaching everything directly to the agent node. Fewer tools = fewer opportunities for the LLM to pick the wrong one. The same principle applies to building applications with no-code tools like Lovable AI — keep the scope of each component narrow and well-defined. Know Your Agent Photo by Daniil Komov on Pexels Building an AI agent you don't understand — where you haven't thought through the system prompt, don't know what happens when a tool fails, and aren't sure why it chose one tool over another — is the same as shipping code you don't understand because an AI wrote it. The consequences arrive later, when something goes wrong and you have no idea where to look. Know three things about your agent before putting it in front of users. First: what does it do when a tool returns an error? Does the agent tell the user, try again, or silently give a wrong answer? Test error scenarios intentionally — disconnect a tool's API and send a message that would trigger it. Second: what does it do when the user's request is ambiguous? Does it ask a clarifying question, or does it guess? Read the system prompt again and make it explicit. Third: how do you know when it's wrong? If the agent makes a mistake and you have no logging, no execution history, and no audit trail, you'll only find out when a user reports it. n8n logs every execution. The execution history shows exactly which tool the agent called, what parameters it passed, and what the tool returned. After building an agent, run 10-15 test cases covering edge cases and common inputs. Read the execution log for each one. You'll find tool selection issues before your users do. When NOT to Use an n8n AI Agent Deterministic workflows where every step is known in advance If a workflow always does step A, then step B, then step C regardless of input, use a regular n8n workflow. Adding an LLM to decide the sequence introduces non-determinism, latency, and cost for no benefit. Agents earn their place when the sequence needs to vary based on what the user asked — not when you can write the sequence down in advance. The n8n vs Make comparison covers this distinction in more detail. Operations that must always execute and can't be skipped An agent decides which tools to call. It can skip a tool, call it in the wrong order, or decide an answer doesn't require a tool at all. If a workflow must always execute a specific action — logging every request, always checking authorization before proceeding — don't put that logic in an agent's toolset. An agent might reason its way around it. Use a regular workflow node that always executes. Sensitive data that can't route through third-party LLMs The AI Agent node sends conversation data to whichever LLM you configure. If the messages contain PII, PHI, financial records, or anything governed by data residency requirements, check whether you can use a self-hosted model (Ollama, a local Mistral instance) before routing through OpenAI or Anthropic. Most n8n AI agent tutorials skip this. It matters for production deployments in regulated industries. Anywhere precision arithmetic or exact outputs are required LLMs are unreliable at arithmetic. An agent calculating invoice totals, applying discounts, or summing financial data will occasionally give wrong answers — confidently. For any calculation, use a Code Tool that performs the math in code and passes the result to the LLM for formatting only. Never let the LLM do the arithmetic itself. Conclusion That product support agent with two tools is still running correctly. The reason is straightforward: the system prompt names the tools and when to use them, the tool descriptions are specific, and the LLM (GPT-4o) makes reliable decisions with that guidance. Change any one of those three things and the error rate changes with it. Use the AI Agent node — not LLM Chain — for tool-calling agents Write a specific system prompt: name each tool and state when to use it Write tool descriptions as sentences that tell the LLM what the tool returns and when it's the right choice Start with Window Buffer Memory; switch to Redis or Postgres when you need cross-session history Test error scenarios deliberately before putting the agent in front of users Use a regular workflow when the execution sequence is always the same The second time an agent correctly identifies which tool to use and returns the right answer, it starts to feel less like an automation and more like a conversation. That feeling is worth something. It's also worth noting that the agent will occasionally pick the wrong tool with full confidence — which is why you read the execution log. ↑ Back to top Frequently Asked Questions How does an n8n AI agent work? An n8n AI agent passes the user's message to an LLM along with a system prompt and a list of available tools. The LLM decides which tool to call — or whether to answer directly — n8n executes the tool, and the result goes back to the LLM to generate a final response. This loop runs until the agent has enough information to answer. Unlike a regular workflow, you don't define the execution order in advance — the LLM decides it dynamically based on the user's input. What LLMs can I use with an n8n AI agent? n8n supports OpenAI (GPT-4o, GPT-3.5 Turbo), Anthropic (Claude 3.5 Sonnet), Google (Gemini), Mistral, Ollama for local models, and others via the LangChain integration. GPT-4o is the most reliable for tool selection in complex scenarios. Smaller or older models make more tool-calling errors — particularly when deciding between tools with similar descriptions. What is the difference between an n8n AI agent and a regular n8n workflow? A regular n8n workflow executes a fixed sequence of nodes you define in advance — the same path every time. An n8n AI agent uses an LLM to decide dynamically which tools to call based on the user's input. Use agents for conversational, context-dependent tasks where the right response varies. Use regular workflows for deterministic automation where the sequence is always the same. How do I add memory to an n8n AI agent? In the AI Agent node, click Memory and select a memory type. Window Buffer Memory keeps the last N messages in context without any storage backend — the simplest option for most use cases. Redis Chat Memory and Postgres Chat Memory persist conversation history across sessions. Start with Window Buffer Memory at a window size of 10; move to a persistent store when users need to return to a previous conversation. Can n8n AI agents call external APIs as tools? Yes. The HTTP Request Tool lets the agent call any REST API. You define the URL, method, headers, and which parameters the agent can set, then give the tool a name and description the LLM uses to decide when to call it. The Code Tool lets you run custom JavaScript or Python as a tool for cases that don't map to a REST API. What should I put in the n8n AI agent system prompt? Tell the agent what it is, what tools it has, when to use each one, and how to respond when it doesn't have enough information. Be specific: "Use get_order_status when the user mentions an order number. Always call the appropriate tool before answering — never answer from memory." Vague system prompts produce vague agents that make tool selection errors and occasionally answer from the LLM's training data rather than calling your tools. Kevin Amayi Full stack developer with 5+ years building TypeScript, Next.js, and Node.js applications. Writes about developer tools, AI coding assistants, and workflow automation — specifically the ones he actually uses on real projects. More from Kevin →

Tag: automation

How to Build an n8n AI Agent: Step-by-Step Tutorial

n8n AI Workflow Tutorial: Build Your First AI Pipeline

Windsurf AI Code Generation Tutorial: A Practical Guide

Quick Links

Resources

Support