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

This skill is the deep guide to designing n8n's AI Agent node (@n8n/n8n-nodes-langchain.agent) and its LangChain sub-node family - a multi-turn LLM driver with slots for model, memory, tools, and an optional output parser, wired via distinct ai_* connection types (ai_languageModel, ai_memory, ai_tool, ai_outputParser) where each sub-node connects FROM itself TO the agent, and multiple tools stack onto the same ai_tool index rather than fanning into separate indices. It opens by picking the right node before wiring anything, since reaching for a full Agent for a one-shot task is the most common over-build: Basic LLM Chain for one-shot text with no tools, Text Classifier for routing natural language into N branches (one node, N output handles - every category needs both a name AND a description, since the model routes against the description and an undescribed category gets picked by coin-flip), Information Extractor for pulling structured fields from free text, Sentiment Analysis for a built-in 3-way split, Summarization Chain for map-reduce document condensing, and a provider's native single-call node (never an Agent) for image/audio/video generation. Two non-negotiables anchor everything else: tool names and descriptions ARE part of the prompt (a tool named tool1 with no description is invisible or mis-selected, with no error surfaced - treat it like API design), and structured output must both parse and auto-fix (outputParserStructured with autoFix: true wired to a second, coding-capable fixer model, since one malformed JSON response otherwise halts the whole workflow). Strong defaults it recommends: keep per-tool usage instructions in the tool description rather than the system prompt (so they travel with the tool and stay out of a bloated prompt); default to sub-workflow tools (.toolWorkflow) for anything multi-step, since a workflow becomes a tool with typed $fromAI() inputs and composes with branching/error handling/reuse; wrap tools with user-visible side effects (sends, payments, refunds, account changes) in human review; raise the low default maxIterations for any multi-tool agent (15 for a focused sub-agent, 50-200 for a broad orchestrator); and put the current date in the system prompt via {{ $now }} rather than a hardcoded, immediately-stale date. It defines four tool types by overhead - a native tool node when one existing node+operation covers the capability, sub-workflow-as-tool as the canonical default for anything reusable or multi-step, HTTP Request Tool for a single external API the agent should orchestrate directly, and MCP Client Tool when a maintained MCP server already covers it - plus a separate Custom Code Tool whose string-in/string-out contract belongs to a companion n8n-code-tool skill. $fromAI() is the expression helper that lets the agent fill a tool parameter, carrying a parameter name, a JSDoc-like description that is itself part of the prompt, an optional type, and an optional default - it is JSON-only and cannot carry binary, so identity/authority/correlation values (user ID, refund caps, session ID) should be plumbed deterministically from workflow context instead, never left for the model to fabricate. A table splits what belongs in the system prompt (persona, global format rules, refusal behavior, universal context) from what belongs in a tool's own description (what the tool does, when to use it, parameter shapes, tool-specific gotchas). Structured output should use schemaType: 'manual' with a real JSON Schema rather than a from-example schema once the shape is non-trivial, always paired with a coding-capable fixer model. Memory is a sub-node: memoryBufferWindow is the chat default (its contextWindowLength defaults to a very low 5; 50 is a saner floor), while Postgres/Redis-backed chat memory is reserved for when memory must be readable outside the agent itself - and the session key must be plumbed consistently from the trigger, never hardcoded to 'default' or left behind $fromAI where the model would fabricate a UUID. The binary/agent boundary is a common trip point: the model can see uploaded images via passthroughBinaryImages, but tools cannot receive binary at all through $fromAI() - the workaround is pre-staging uploads to storage and passing string keys for tools to re-fetch. Human review wraps a destructive tool between itself and the agent with a review node (slackHitlTool and siblings), and the approval message must show the tool's actual literal parameters ({{ $tool.parameters.<name> }}), never a $fromAI() paraphrase the model could have fabricated. Chat agents (Slack/Discord/Teams/Telegram) have one non-negotiable regardless of complexity: filter out the bot's own user ID or its replies will re-trigger it in an infinite loop; beyond that, splitting into shell (trigger, anti-loop filter, UX, no LLM), core (stateless agent keyed on threadId), and sub-agents (narrow, stateless, called via .toolWorkflow) only pays off once loading UX, multiple sub-agents, or multi-surface reuse are actually needed. For RAG, it advises ruling out cheaper lookups first (a database query for exact lookups, a live search tool for freshness, list/fetch tools for a small structured doc set) and wiring a vector store as a retrieval tool (mode: 'retrieve-as-tool') so the agent decides when retrieval is relevant, embedding queries and documents with the same model.

Use it for n8n AI Agent, LangChain, classifier, extractor, memory, RAG, tool-calling, structured-output, or human-review design - always confirming the target n8n instance and inspecting the live node schema before applying version-sensitive configuration, and showing the user the exact effects of any workflow that can send messages, write data, make purchases, or call external services before activating or testing it. Do NOT wrap image/audio/video generation in an Agent (binary doesn't flow through tool calls or agent output), reach for an Agent+Switch combination where a single Text Classifier node would do, or store provider keys anywhere but n8n credentials (never in prompts, Set nodes, workflow JSON, or logs).

Inputs: the task requiring an LLM decision (tool use, classification, extraction, multi-turn conversation), the available tools and their real capabilities, and any memory/session context. Outputs: a correctly node-typed workflow (Agent vs Chain vs Classifier vs Extractor), wired sub-nodes for model/memory/tools/output-parser via their ai_* connections, tool names and descriptions written like API documentation, a validated outputParserStructured with autoFix, and - where needed - a human-review gate showing real tool parameters before a destructive action fires.

"Main LLM": {
  "ai_languageModel": [[{ "node": "AI Agent", "type": "ai_languageModel", "index": 0 }]]
},
"Simple Memory": {
  "ai_memory": [[{ "node": "AI Agent", "type": "ai_memory", "index": 0 }]]
},
"Search customer DB": {
  "ai_tool": [[{ "node": "AI Agent", "type": "ai_tool", "index": 0 }]]
}

Built on n8n's LangChain node family (@n8n/n8n-nodes-langchain.agent and its chat-model, memory, tool, and output-parser sub-nodes), and cross-references a full set of companion skills: n8n-workflow-patterns for the high-level agent-in-workflow shape, n8n-mcp-tools-expert for node-type format rules, n8n-code-tool for the Custom Code Tool contract, n8n-subworkflows for the .toolWorkflow primitive, n8n-binary-and-data for the agent-tool binary boundary, n8n-validation-expert for interpreting validate_workflow, and n8n-error-handling for tool/agent error UX.

n8n workflow builders designing AI Agent-driven automations who need the tool, memory, structured-output, and human-review patterns that make an agent actually reliable in production, not just working in a demo.