n8n + OpenAI: Build an AI Agent Step by Step

A normal n8n workflow follows the path you drew. An agent decides its own path: it gets a request, looks at the tools you gave it, calls one, reads the result and decides what to do next. That difference is the whole point — and also the reason agents cost more and behave less predictably than the workflow you already know how to build.

This guide assumes you have built a basic workflow already. If not, start with your first n8n workflow — agents are much easier to reason about once triggers and nodes are familiar.

Use an Agent Only When You Need One

This is the decision most tutorials skip, and getting it wrong is expensive. If you know the steps in advance, a fixed chain of nodes is cheaper, faster and far easier to debug. An agent earns its place only when the next step genuinely depends on what the previous one returned.

The Four Pieces

An agent in n8n is one main node with sub-nodes clipped underneath it. The sub-nodes attach to the AI Agent node rather than sitting in the main left-to-right flow, which surprises people the first time.

Simple Memory was previously called Window Buffer Memory, so older tutorials and screenshots use that name for the same thing.

Build It, Step by Step

1. Add a trigger. For a conversational agent use When chat message received, which gives you a chat box to test in and passes a session id automatically.
2. Add the AI Agent node after the trigger. Its empty sub-node slots appear underneath it.
3. Attach a Chat Model sub-node and connect your OpenAI credential. Start with a mid-tier model — agent loops call the model repeatedly, so the difference in cost is multiplied, not fixed.
4. Write the system prompt on the agent node. This is the part that decides whether the agent works; see below.
5. Attach Simple Memory if the agent should remember earlier messages in the same conversation. Set the Context Window Length to cap how much history it carries.
6. Attach one tool and test with it before adding more. An agent with five untested tools is nearly impossible to diagnose.
7. Test through the chat box, read the intermediate steps, then Publish — the same rule as any workflow: it does not run on its own until you do.

The System Prompt Is a Job Description

Most failing agents fail here rather than in the wiring. The system prompt has to say what the agent is for, when to use each tool, and what to do when it cannot answer — because the model chooses tools by reading their descriptions and your instructions, not by magic.

Three things belong in it that people routinely leave out: an explicit boundary («if the question is not about X, say so rather than guessing»), a rule for missing information («ask for the order number instead of inventing one»), and the format you expect back. Vague prompts produce agents that call the wrong tool confidently.

Tools: Description Quality Decides Everything

A tool's description is not documentation for you — it is the text the model reads when deciding whether to call it. «Gets data» gives the agent nothing to choose on. «Looks up an order by its ID and returns status and delivery date» tells it exactly when this tool is the right one.

Give each tool one job. Two agents with three narrow tools each are easier to debug than one with six overlapping ones, and the model picks correctly far more often.

What Simple Memory Really Is

Simple Memory keeps a rolling window of the recent conversation and injects it before each new message. It is keyed by a session id — with the chat trigger, n8n fills that in for you, which is why conversations stay separate per user without extra work.

Two honest limits. First, it is a window, not a database: once the conversation exceeds the Context Window Length, the earliest messages fall out and the agent genuinely does not know them any more. Second, n8n advises against relying on this node in production when running in queue mode, because a follow-up message may be handled by a different worker that has no copy of it. For anything real and multi-user, plan on external storage instead.

Why Agents Fail

• Using an agent where a fixed workflow would do — slower, costlier, harder to debug, with no benefit.
• A vague system prompt, so the agent picks tools by guesswork.
• Tool descriptions written for humans rather than for the model.
• Too many tools at once, making it impossible to tell which choice went wrong.
• Assuming memory persists forever — it is a rolling window and drops the oldest messages.
• Not looking at the intermediate steps, so you debug the final answer instead of the decision that produced it.
• Forgetting that every loop iteration is another paid model call.

Cost and Control

A fixed workflow calls the model once, if at all. An agent may call it several times per run — once to choose a tool, again to interpret the result, again to decide whether it is finished. Costs scale with how much freedom you give it, which is another argument for narrow tools and a precise prompt.

If cost matters, cap the agent's iterations and keep the expensive model for the reasoning step only. Not everything in the workflow needs to be the agent's decision.

Where to Go Next

If any of the vocabulary is still in the way, the n8n glossary covers the core terms and the n8n knowledge base explains how the pieces fit. For pricing and honest limitations, see the n8n tool page.

Bottom Line

Building the agent is the easy part: one node, three sub-nodes, half an hour. Making it reliable is the work, and it lives almost entirely in the system prompt and the tool descriptions.

Start with one tool and a boring, specific prompt. Add capability only after the simple version behaves. And before you build anything, ask honestly whether the steps are actually unpredictable — if they are not, the fixed workflow you already know how to build will beat the agent on every axis that matters.