TL;DR: Most "agentic" n8n workflows should not be agentic. Default to a deterministic pipeline with a single AI Agent node doing the one reasoning step that genuinely needs judgment. Reach for a single agent with tools when the task needs real tool selection, and only build an orchestrator with sub-agents (using the AI Agent Tool sub-node) when you have distinct skill domains that each warrant their own system prompt and tool set. Every agent needs a Max Iterations cap, a tight tool list, and a reason to exist beyond "AI is cool." This is an architecture piece, not a node reference.
The three patterns, ranked by how often you should use them
There are exactly three agentic shapes worth building in n8n, and they are not equally useful. In rough order of how often they earn their place:
- Deterministic pipeline with one agent step. Your workflow is mostly normal nodes - triggers, HTTP requests, Set, IF, database writes - with a single AI Agent node dropped in at the one spot that needs judgment. This is the right answer most of the time.
- Single agent with tools. One AI Agent node that decides, on its own, which tools to call and in what order. Use this when the sequence of actions genuinely depends on the input and you can't hard-code it.
- Orchestrator with sub-agents. A top-level agent that calls other agents as tools via the AI Agent Tool sub-node. Reserve this for cases with clearly separate skill domains that each need their own prompt, model, or tool set.
The mistake we see repeatedly is people starting at pattern 3 because multi-agent diagrams look impressive, then spending two days debugging why the orchestrator keeps calling the wrong sub-agent. Start at the top of the list and only move down when the workflow forces you to.
Pattern 1: Deterministic pipeline with one agent step
This is your default. The agent does not control the flow - your nodes do. The agent handles exactly one task that resists hard-coding: classify this email, extract structured fields from this messy text, draft a reply, decide which of three routes a ticket belongs to.
Everything around it is deterministic. The webhook fires, you fetch the record, you call the agent for the one judgment call, then you branch on its output with a normal Switch node and write to your database. The agent never touches the tools, never loops, never surprises you on the billing side.
The key technique here is forcing structured output so the rest of the workflow can rely on the shape of the response. In the AI Agent node, enable Require Specific Output Format and connect a Structured Output Parser sub-node. Then your downstream Switch reads a clean field instead of trying to regex an LLM's prose.
A minimal classifier agent's system message looks like this:
You are a support ticket classifier. Read the ticket and return JSON only.
Categories: billing, technical, sales, other.
Set "urgent" to true only if the customer mentions an outage, data loss,
or a legal threat. Do not guess. If unclear, use "other".
And the parser's expected schema:
{
"type": "object",
"properties": {
"category": {
"type": "string",
"enum": ["billing", "technical", "sales", "other"]
},
"urgent": { "type": "boolean" }
},
"required": ["category", "urgent"]
}
Why this is the default: it is debuggable. Every step is visible in the execution log, the agent has no tools to misuse, and the cost per run is one model call you can predict. You get the value of an LLM (judgment on unstructured input) without inheriting the risks of autonomy. If a stakeholder asks "what will this do?", you can answer with certainty, which you cannot do for a free-roaming agent.
Pattern 2: Single agent with tools
Move up to this pattern when the order and selection of actions depends on the input in a way you cannot express as a flowchart. A customer-facing assistant that might need to look up an order, check inventory, or issue a refund - depending entirely on what the customer asks - is the canonical case. You don't know in advance which of those it will need, so you let the agent decide.
In n8n this is the AI Agent node with tool sub-nodes attached to the Tool connector. Since version 1.82.0, the AI Agent node operates as a Tools Agent by default; the old dropdown that let you pick Conversational, ReAct, or OpenAI Functions variants was removed, and you must connect at least one tool. You attach tools by dragging from the node's tool port: a Calculator, an HTTP Request Tool, a Call n8n Workflow Tool, a Vector Store Question Answer Tool, the MCP Client Tool, and so on.
The piece that makes tools actually work is $fromAI(). It lets the model fill in a tool's parameters from context instead of you hard-coding them. The function signature is $fromAI(key, description?, type?, defaultValue?). In a Call n8n Workflow Tool, click "Let the model define this parameter" on a field and you get an expression like:
$fromAI('customerEmail', 'The email address of the customer asking the question', 'string')
The model reads the conversation, finds the email, and passes it to your sub-workflow. The description argument matters more than people expect: it is effectively a mini-prompt telling the model what to extract, so write it precisely.
Keep the tool list short
The single biggest quality lever on a tools agent is giving it fewer tools. Every tool you attach is another thing the model can pick wrong. An agent with four sharp tools (getOrder, checkInventory, issueRefund, escalateToHuman) outperforms one with fifteen overlapping ones. If two tools do similar things, merge them or remove one. If a tool is only relevant in a narrow branch, that branch probably wants pattern 1 instead.
This is also where skill files pay off. Instead of stuffing every instruction into one bloated system message, you can give the agent structured, reusable knowledge about your tools and conventions. We cover the mechanics in AI agent skill files for n8n.
Pattern 3: Orchestrator with sub-agents
Only build this when you have genuinely distinct skill domains. The signal that you've crossed the line is that a single system message starts contradicting itself - "be terse and technical for support questions, but warm and persuasive for sales questions, and rigidly factual for billing" is three jobs, not one. At that point, split them.
n8n supports agent-as-tool natively through the AI Agent Tool sub-node. You build a specialist agent (its own system message, its own model, its own narrow tool set) and expose it as a callable tool on a top-level orchestrator agent. The orchestrator's job shrinks to routing: read the request, decide which specialist handles it, hand off, and assemble the result.
A practical layout for a support automation:
-
Orchestrator agent - system message is purely about routing. "You coordinate specialists. Do not answer directly. Pick the right specialist and pass the full question."
-
Billing specialist (AI Agent Tool) - tools for the billing system, a system message tuned to refunds and invoices.
-
Technical specialist (AI Agent Tool) - access to a documentation vector store, tuned to troubleshooting.
-
Escalation tool (Call n8n Workflow Tool) - a plain sub-workflow, no agent, that opens a human ticket.
Note that not every "specialist" needs to be an agent. The escalation step is deterministic, so it's a Call n8n Workflow Tool, not an AI Agent Tool. Mixing agent and non-agent tools on the same orchestrator is normal and good - reserve the expensive agentic specialists for the steps that need reasoning.
The cost and latency math is the catch. An orchestrator that calls one specialist, which itself calls two tools, is at minimum four model round-trips for one user request. If you're tempted to nest a third layer of agents, stop and ask whether the bottom layer should just be a deterministic sub-workflow. Depth is where multi-agent systems become unobservable and expensive.
When to use memory (and when it quietly breaks things)
Add a memory sub-node only when the task is a genuine multi-turn conversation. A chat assistant that needs to remember what "it" refers to two messages later needs memory. A workflow that fires once per webhook and returns one answer does not - and bolting memory onto it usually introduces bugs rather than features.
n8n's memory sub-nodes attach to the agent's Memory connector: Simple Memory for in-workflow session history, plus Postgres Chat Memory, Redis Chat Memory, and others for durable storage. Two things to internalize:
First, Simple Memory does not persist between sessions or survive restarts - it lives in the workflow execution context. For anything that needs to remember a user across days, use a backed store like Postgres Chat Memory and set the session key deliberately.
Second, memory is keyed by a session ID. If every execution uses the same hard-coded key, you've merged every user's conversation into one shared brain - a real and common bug. Drive the key from something stable and per-user, such as a chat ID or customer ID from the trigger payload.
If your "agent" doesn't hold a conversation, skip memory entirely. It's not free context; it's another moving part and another way to leak data between users.
Guardrails every agentic workflow needs
Autonomy without limits is how a workflow runs up a bill or loops forever. Treat these as mandatory, not optional.
Cap Max Iterations. In the AI Agent node options, set a hard ceiling on tool-calling cycles. The default is generous. For a focused tools agent, a low single-digit cap is usually plenty, and hitting the cap is a signal that your tools or prompt are wrong, not that you need a higher cap.
Watch for tool loops. Agents get stuck calling the same tool with slightly different arguments when a tool returns ambiguous results. Turn on Return Intermediate Steps while developing so you can see the agent's reasoning and tool calls in the execution log. The fix is almost always a clearer tool description or a tool that returns a definitive answer instead of a maybe.
Budget for cost. Multiply your worst-case iterations by your model's per-call cost and your daily volume before shipping. A tools agent that occasionally loops to its iteration cap costs far more than a single-call pipeline. If the numbers scare you, that's pattern 1 telling you it wanted the job.
Constrain the dangerous tools. Any tool that writes, pays, sends, or deletes deserves a deterministic guard around it - a Switch that requires explicit confirmation, a spending threshold, or a human-in-the-loop step. Don't let the model be the only thing standing between a hallucination and a refund.
When NOT to use an agent at all
If you can draw the workflow as a flowchart with no ambiguous branches, you don't need an agent - you need an IF or Switch node. Agents earn their cost only when the decision genuinely requires reading unstructured input and exercising judgment. Fixed routing, scheduled jobs, data syncs, and format conversions are all deterministic. Putting an LLM in charge of them adds latency, cost, and nondeterminism in exchange for nothing.
A useful test: write down the rule. If you can state the routing logic as a complete set of if-then conditions, code those conditions. If you genuinely cannot - because the input is freeform language and the categories blur - that's where the agent belongs.
How the patterns connect to RAG and MCP
These patterns compose with the rest of your n8n AI stack rather than replacing it.
Retrieval fits as a tool, not a separate architecture. In a tools agent or a specialist sub-agent, attach a Vector Store Question Answer Tool so the agent can pull relevant context on demand. The full build, including embeddings and chunking, is in our n8n RAG workflow guide.
External capabilities arrive through MCP. The MCP Client Tool lets an agent call tools served by an MCP server, which is how you give one agent access to a whole catalog of capabilities without wiring each one by hand. If you're exposing your own workflows to agents, see setting up an n8n MCP server.
The architecture decision still comes first. RAG and MCP are tools you hang off an agent; they don't tell you whether you needed an agent in the first place. Pick the pattern, then attach capabilities.
FAQ
What is an agentic workflow in n8n?
An agentic workflow is one where an AI Agent node decides which actions to take, rather than following a fixed sequence of nodes. The agent reads input, chooses tools, and may loop until it reaches an answer. In n8n this is built with the AI Agent node plus tool and memory sub-nodes. Most workflows people call "agentic" are better built as a deterministic pipeline with a single agent step.
Does n8n support multiple agents in one workflow?
Yes. The AI Agent Tool sub-node lets you expose one agent as a callable tool on another agent, which is how you build orchestrator-and-specialist (multi-agent) patterns. Each agent keeps its own system message, model, and tools. Use this only when you have genuinely distinct skill domains; for most cases a single agent with a tight tool list is simpler and cheaper.
How do I attach tools to an n8n AI Agent?
Drag a connection from the AI Agent node's Tool port to a tool sub-node such as Calculator, HTTP Request Tool, Call n8n Workflow Tool, or MCP Client Tool. Since version 1.82.0 the AI Agent node runs as a Tools Agent and requires at least one tool. Use the $fromAI() expression to let the model fill in a tool's parameters from context.
When should I add memory to an n8n agent?
Add a memory sub-node only for genuine multi-turn conversations where the agent must recall earlier messages. Single-shot workflows that answer one request per trigger do not need it. When you do use memory, key it by a stable per-user session ID, and use a backed store like Postgres Chat Memory if it must survive restarts, since Simple Memory does not persist between sessions.
How do I stop an n8n agent from looping or running up costs?
Set a low Max Iterations cap in the AI Agent node options, enable Return Intermediate Steps during development to inspect tool calls, and put deterministic guards around any tool that writes, pays, or deletes. Hitting the iteration cap is a sign the tools or prompt need fixing, not that the cap is too low.
Single agent or multi-agent - which should I default to?
Default to a deterministic pipeline with one agent step, and only move to a single agent with tools when the sequence of actions truly depends on the input. Reserve multi-agent orchestration for cases where one system message would have to contradict itself across separate skill domains. More agents means more model calls, more latency, and harder debugging.
If you've outgrown pattern 1 and your orchestrator is starting to feel unobservable, that's usually the point where an outside review saves more than it costs. We build and audit agentic n8n workflows for teams that want the architecture right before the bill arrives - reach out if that's where you are.
