How to Build AI Agents with n8n — Step by Step (No Code)

What the AI Agent node is actually doing

The regular LLM node in n8n is a single API call with no state: you send a prompt, get back text, the workflow moves on. The AI Agent node runs a different pattern — the ReAct loop (Reasoning + Acting), which is the same pattern that drives agents in LangChain, AutoGPT, and most production AI systems today.

In practice, this means the agent can do things in sequence based on what it learns. A support agent receives a customer message about a missing order. It reasons that it needs the order details before answering. It calls the "Get Order" tool (an HTTP Request to your fulfillment API). It reads the response — order is in transit, last scanned in Dallas — and uses that live data to write an accurate, specific reply. No hallucinated shipping dates. No generic "please contact support."

n8n's implementation of this is built on LangChain under the hood, which means it inherits LangChain's tool calling format. The model sees your tools as a structured list with names and descriptions, and it chooses which ones to call based on what the task requires. The quality of those tool descriptions turns out to matter enormously — more on that in the tools section.

One setting to know before you start: Max Iterations. This caps how many Reason → Act → Observe cycles the agent can run per execution. The default is 10. For most support or lookup tasks, 3–5 iterations is plenty. If you set it too low, the agent stops mid-task; too high, and a poorly-configured agent can run expensive loops. For initial development, leave it at 10; in production, dial it down to match your use case once you understand the real iteration count.

Building your first agent — step by step

The simplest useful agent: a customer FAQ bot that responds to messages in a Slack channel or via a webhook. No memory, no external tools — just the agent with a well-configured system prompt. This is the right starting point because it lets you understand how the model behaves before you add complexity.

You are the support assistant for Acme Store. You answer customer questions about orders, returns, shipping, and products.

Company context:
- Orders ship within 2 business days via DHL Standard
- Returns accepted within 30 days, items must be unused
- Standard shipping takes 5–7 business days; express takes 2
- Customers can track orders at acme.com/track using their order number

Rules:
- If you don't have enough information to answer accurately, say so and ask the customer for their order number or email
- Never make up shipping dates, order statuses, or policies not listed above
- Keep replies under 120 words
- Use plain language, no jargon

System prompts that actually work

The two most common system prompt failures: (1) too broad — the agent doesn't know when to stop and ask for clarification; (2) too detailed — the prompt becomes so long that the model starts ignoring parts of it when the context window fills with conversation history.

The structure that works reliably in production has four components: role and context (who the agent is and what it serves), what it knows (the static facts it can answer from without tools), what tools it has (briefly described, so the agent understands when to use them), and behavioral constraints (format of replies, what to do when uncertain, escalation rules).

Two specific patterns worth noting. First, explicit uncertainty handling — "If you cannot answer from the information available to you, respond with 'I need to check on that' and specify what information you'd need from the customer." This prevents the model from guessing confidently when it should be asking. Second, output format constraints — "Always structure your final response as a single paragraph, no bullet points, under 150 words." Agents left to their own devices tend to over-format with headers and lists, which looks wrong in a chat interface.

Adding memory: the step most tutorials skip

Without memory, every message to your agent starts a fresh conversation. The customer says "I have a problem with my order," the agent asks for the order number, the customer provides it — and then, if they ask a follow-up question two messages later, the agent has no idea what order they were talking about. This is the behavior that makes users feel like they're talking to a particularly forgetful chatbot.

Memory in n8n works by attaching a Memory node to the AI Agent node's memory port (the small connector at the bottom). n8n offers three memory types, each suited to a different stage of deployment:

The configuration that most guides miss is the Session ID. Without it, all users share the same memory — user A's order number bleeds into user B's conversation. The Session ID field in the memory node should be set to a unique identifier per user or conversation: for Slack, use the channel ID + user ID combination ({{ $json.event.channel }}_{{ $json.event.user }}); for a web chat, pass a UUID from the frontend; for email, use the email thread ID. This single configuration decision separates a toy agent from one that actually works in multi-user production.

For initial development, use Window Buffer Memory. Once the agent behavior is stable and you're moving to production, switch to Redis Chat Memory — add a Redis connection, set the TTL to 24 hours (or whatever makes sense for your use case), and the memory becomes persistent across n8n restarts and workflow updates.

Connecting tools: making the agent useful

Tools are what separate an AI agent from a standard chatbot. The agent node's tool port (the third connector) accepts any number of connected tool nodes — and the model decides which ones to call, and when, based on their descriptions. You can connect n8n's built-in tool nodes, use HTTP Request as a tool (to call any external API), or point to another n8n workflow as a sub-agent tool.

Built-in tools

n8n ships with several tools that can connect directly to the agent: Calculator (for arithmetic that LLMs frequently get wrong), Wikipedia (real-time lookup), Wolfram Alpha (computation and fact-checking), and SerpAPI (web search). These are the easiest starting point — add one, connect it to the agent's tool port, and the agent can use it. No configuration needed beyond an API key for search tools.

The Calculator tool is often overlooked but surprisingly valuable. LLMs are unreliable at arithmetic — GPT-4o can confidently return a wrong subtraction result when the inputs are multi-digit numbers. For any agent that handles pricing, quantities, dates, or numeric lookups, the Calculator tool ensures the math is always correct. Connecting it adds one node and costs nothing.

HTTP Request as a tool

This is the pattern you'll use most in production. The HTTP Request tool node lets the agent call any external API — your CRM, your fulfillment system, your database via an API endpoint, your custom internal tool. The key configuration: the Tool Description field. This is what the agent reads to decide when to call this tool. Write it precisely.

A weak description: "Gets order information." The agent doesn't know when this applies vs. other tools, or what input it requires.

Use this tool to retrieve the status, tracking number, and delivery estimate for a customer order.
Required input: the customer's order number (format: ORD-XXXXX).
Returns: order status (processing/shipped/delivered/returned), carrier, tracking number, expected delivery date.
Call this tool when: the customer asks about their order status, wants to track a shipment, or mentions an order number.

The "When to call this tool" instruction at the end is the most important part. Without it, the agent sometimes calls the tool unnecessarily (wasting API budget) or skips it when it should use it. Explicit triggering conditions make tool selection reliable.

n8n workflow as a tool

The most powerful pattern for complex agents: any existing n8n workflow can be connected as a tool via the Call n8n Workflow tool node. This means you can build specialized sub-workflows — one that queries your database, one that checks inventory, one that runs a multi-step lookup — and the agent calls them as black-box tools. The agent doesn't need to know how the workflow works internally; it just calls it with an input and receives an output.

This architecture also makes testing much easier. You test the sub-workflow in isolation, confirm it returns correct results, and then connect it to the agent. Any bug in the sub-workflow is isolated to that workflow; you don't need to re-run the entire agent loop to debug it.

A production-ready support agent (full example)

Here's how all the components come together in a real deployment. This is a customer support agent for an e-commerce business, handling tier-1 support via a chat widget on the website. It can answer general questions from its system prompt, look up order status via API, and escalate complex cases to a human agent in Slack.

The escalation detection step after the agent is worth explaining. The agent's system prompt instructs it to include a specific flag in its output when escalation is needed: "If the issue cannot be resolved in this conversation (damaged item, payment dispute, address change), include the text [ESCALATE] somewhere in your response." The IF node checks for this string. If found, the full conversation context is posted to the #support-escalations Slack channel with the customer's details and conversation history, so a human can pick it up without asking the customer to repeat themselves.

Before this agent went live, the team handled tier-1 support manually — about 80 tickets per week, averaging 8 minutes each. The agent now handles ~65% of those without escalation. The remaining 35% escalates to human agents with full context. Total manual support time dropped from 10+ hours per week to roughly 3.5 hours, with first-response time going from average 4 hours to under 30 seconds.

The Order Lookup tool makes about 30% of conversations accurate in a way a static system prompt never could be — because it's pulling real-time data from the fulfillment API, not guessing from training data. That's the core value proposition of agents over standard LLM calls: when accuracy depends on current information, the agent fetches it.

When things break — and they will

The four failure modes that appear most in production n8n agent deployments, and how to fix each one:

n8n's execution history is the primary debugging tool — you can see every iteration of the agent loop, which tools were called with what inputs, and what each tool returned. Open the execution log for a failed run and step through the loop iterations one by one. The issue is almost always visible in the second or third iteration.

When an agent is the wrong tool

Agents add latency, cost per execution, and debugging complexity that a simpler workflow doesn't. They're worth it when the task genuinely requires dynamic decision-making — when the sequence of steps depends on intermediate results. They're not worth it when the task is predictable.

Use a regular LLM node (not an agent) for: email classification (is this a billing question, a support question, or spam?) — the input is one email, the output is one category, no tools needed. Tone rewriting — takes a text, outputs a rewritten version. Single-field extraction — pull the invoice amount from a PDF text. These are single-step transformations. Agents would add latency and cost without benefit.

Use an AI agent for: tasks where the answer depends on information you need to retrieve dynamically. Tasks where the right sequence of steps depends on what was found in a previous step. Conversational interfaces where the agent needs to maintain context across exchanges. Multi-step research — find information, evaluate it, decide whether to dig deeper or return.

Frequently Asked Questions

Related Articles