Build multi-turn AI agents with tools, memory & routing

n8n Agents is a deep guide to designing AI agents in n8n and the LangChain-family nodes around them: agents, chains, classifiers, extractors, tool calling, memory, RAG, structured output and human-review flows. It is a community skill by Romuald Czlonkowski (czlonkowski/n8n-skills) under the MIT license. The AI Agent node (@n8n/n8n-nodes-langchain.agent) is a multi-turn LLM driver with sub-nodes for the model, memory, tools and an optional output parser. In workflow JSON the LangChain nodes use the long @n8n/n8n-nodes-langchain.* form, while get_node and validate_node calls use the short nodes-langchain.* form.

Pick the right node first. Using an Agent for a one-shot task is the most common over-build. Use the AI Agent for tools, multi-turn reasoning or memory; a Basic LLM Chain for one-shot text in and out; a Text Classifier to route natural-language input to one of N branches (one node with N output handles, instead of an Agent plus a Switch); an Information Extractor for schema-based field extraction; Sentiment Analysis for a positive, neutral or negative split; a Summarization Chain for long documents; and the provider's native single-call node for image, audio or video generation, never an Agent. Text Classifier categories need both a name and a description, since the model routes on the description, and enableAutoFixing helps with edge inputs. Chat-model nodes are sub-nodes that connect through ai_languageModel.

The sub-node pattern. An agent has a main input and up to four sub-node slots, each wired by its own connection type: model (ai_languageModel, required), memory (ai_memory), tools (ai_tool) and an output parser (ai_outputParser). The connection lives on the sub-node and points to the agent:

"Main LLM": {
  "ai_languageModel": [[{ "node": "AI Agent", "type": "ai_languageModel", "index": 0 }]]
},

Multiple tools all connect into the same ai_tool index 0. The agent's answer is in $json.output.

Two non-negotiables. First, tool names and descriptions are part of the prompt: a tool named tool1 with no description is invisible to the model, which skips it or invents parameters, usually without any error. Second, structured output must parse and auto-fix: an outputParserStructured with autoFix: true and a coding-capable fixer model is the production pattern, since one malformed response otherwise halts the workflow.

Strong defaults. Put per-tool usage in the tool description, not the system prompt. Use sub-workflow tools (.toolWorkflow) for anything multi-step, with typed $fromAI() inputs. Wrap tools with user-visible side effects in human review. Raise maxIterations (the default is a single-digit cap; about 15 for a focused sub-agent and 50 to 200 for a broad orchestrator). Put the current date in the system prompt with {{ $now }}.

Four tool types. A native tool node (lowest overhead), a sub-workflow tool (the canonical default when in doubt), an HTTP Request Tool for a single external API, and an MCP Client Tool when a maintained MCP server already covers the job. A Custom Code Tool exists for pure inline computation, but if you need $fromAI() inside the code you want a sub-workflow tool instead. $fromAI() takes a parameter name, a description that is itself prompt text, an optional type (string, number, boolean or json) and an optional default; it carries JSON only, never binary. Identity, authority limits and session IDs should be plumbed deterministically so the agent cannot get them wrong or even see them.

Human review has more detail. The review node is invisible to the agent, and models often hedge on destructive-looking tools, so when an agent over-hedges on a wrapped tool, add a note to that tool's description saying it is gated by a human review step and should be used freely; do not add the note preemptively. Review is recommended for sends, payments, refunds and account changes, when the approver differs from the chatter (a customer triggers a workflow and support staff approve in Slack), for non-chat triggers such as an order received, a form submission or a schedule, and for production tools where a wrong call costs money or trust; it can be skipped for read-only, idempotent, cheap-to-undo tools and internal or mocked deployments. Review nodes exist for Slack, Discord, Telegram, Gmail, generic SMTP email, Google Chat and Outlook. The response type is approval (single or double button, with custom labels that carry the amount), free text, or a custom form, which is the supported way to allow edited parameters. The wait limit defaults to 45 minutes and should be set explicitly in production. The approval message should iterate over all tool parameters so a new parameter is never silently left out, and the button label should name the value being approved.

Memory has more detail too. contextWindowLength defaults to 5, and messages past the window are dropped entirely, so raise it (50 is a reasonable start) or persist key facts in a Data Table injected into the system prompt. A Chat Memory Manager node offers load, insert (with a hide-from-UI option) and delete modes, enabling rolling summarization. Memory stores text turns only, so uploaded files must be re-introduced through a per-session file inventory in the system prompt. Mistakes to avoid include a shared default session, different session IDs on memory and tools, unbounded buffers, memory where there is no session, expecting tools to see memory, and drift when something posts to the conversation outside the agent without being inserted into memory. Memory size drives token cost, since a 15-turn buffer of 200-token messages is about 3000 input tokens every turn. The system prompt should hold persona, global format rules, refusal behavior, display protocols and universal context, while tool-specific usage lives in tool descriptions. Tool descriptions have three parts, names are verb-first, and near-identical tools are merged into one tool with a branching parameter. Sub-agents in chat bots are stateless, with full context passed in their input.

Use it for n8n AI Agent, chain, classifier, extractor, memory, RAG, tool-calling, structured-output or human-review design. Confirm the target n8n instance and inspect the live node schema first, because node types, parameters, model availability and defaults vary by version. Before activating or testing a workflow that can send messages, write data, make purchases, change accounts or call external services, show the user the exact effects and get approval. Store provider keys only in n8n credentials, never in prompts, Set nodes, workflow JSON, examples or logs.

Limits: the guidance cannot set provider secret values or prove a live multi-turn agent works without an authorized execution, and validation does not prove tool selection quality, correct wiring, idempotency or safe side effects. Setting a workflow's Error Workflow is a UI-only step.

Structured output should use schemaType: 'manual' with a real JSON Schema rather than an example, because an example cannot express required fields, enums or ranges, plus a "do not wrap the output in a markdown code block" retry instruction. Memory is a sub-node: without it every call is stateless; memoryBufferWindow is the chat default, with a context window that defaults to a very low 5 and is better started at 50; Postgres or Redis chat memory is only for reading memory outside the agent. Use a stable session key from the trigger, such as Slack thread_ts, and never a hardcoded 'default' or a key filled through $fromAI().

Binary has a hard boundary: the model can see uploaded images with passthroughBinaryImages, but tools cannot receive binary and the agent output is text-shaped, so pre-stage files in storage and pass keys as strings. Human review wraps a destructive tool with a review node (Slack, Discord, Telegram or Gmail variants), between the tool and the agent, and the approval message must show literal {{ $tool.parameters.<name> }} values rather than a model paraphrase. Chat agents must filter out the bot's own user ID or their replies retrigger them in an infinite loop; larger bots split into a shell (trigger, filter, switch, loading and error UX), a stateless core and narrow stateless sub-agents called as tools. For RAG, rule out cheaper lookups first (exact lookups are database queries, fresh data needs live search, small document sets can use list and fetch tools), then wire the vector store as a retrieval tool and embed queries and documents with the same model.

The pre-ship checklist covers the right node, model wiring, verb-first tool names with real descriptions, specific $fromAI() descriptions, $now, raised maxIterations, stable memory keys, structured output with autoFix, human review on destructive tools, the bot filter, binary handling, and validation with validate_workflow and n8n_get_workflow.

It works with n8n and its MCP tools (search_nodes, get_node, validate_node, validate_workflow, n8n_update_partial_workflow, n8n_test_workflow, n8n_get_workflow), and pairs with the companion n8n skills for workflow patterns, node configuration, expression syntax, the code tool, sub-workflows, binary data, validation and error handling.

It suits automation builders and engineers designing AI agents in n8n who want reliable tool selection, safe approval flows and maintainable chat bots.