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

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.

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.

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

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.

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.

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

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.

Frequently Asked Questions