FlowKit

Getting started with n8n's AI nodes: agents, chains and memory

Published 2 June 2026 · 3 min read

Open the node panel of a recent n8n and the AI section can be intimidating: agents, chains, models, memories, parsers, retrievers, tools. The good news is that it all reduces to one mental model. Master it and every AI workflow — including every template we sell — becomes readable at a glance.

The mental model: root nodes and sub-nodes

Classic n8n nodes pass data left to right through main connections. AI nodes add a second dimension: cluster nodes. A root node (Agent, Basic LLM Chain, Q&A Chain) sits in the main flow like any node — but its capabilities plug in underneath, as sub-nodes with typed connections:

  • ai_languageModel — the brain: OpenAI Chat Model, Anthropic Chat Model…
  • ai_memory — conversation state: Window Buffer Memory…
  • ai_tool — things an agent may call: HTTP Request Tool, workflows, vector stores
  • ai_outputParser — structure enforcement: Structured Output Parser
  • ai_embedding, ai_vectorStore, ai_retriever, ai_document, ai_textSplitter — the RAG family

The key consequence: capabilities are composable and swappable. The model is not welded to the logic; swap the model sub-node and everything else stands.

The three root nodes you'll actually use

Basic LLM Chain — one prompt, one completion, no autonomy. This is the workhorse: classification, summarization, extraction, drafting. Add a Structured Output Parser and set hasOutputParser and the model must return your JSON schema — enums for categories, integers for scores — so Switch and IF nodes downstream can route on solid values.

AI Agent — a model with tools and, usually, memory. The agent reads the conversation, decides whether to call a tool, reads the result, iterates. Use it when the flow genuinely depends on what the user says: guided interviews, assistants that fetch data. Two rules keep agents reliable: narrow tools with excellent descriptions (the description is what the model reads to decide), and a system message that spells out the protocol step by step. Our guided questionnaire bot is a complete worked example — 8 questions, one recording tool, mandatory tool call after each confirmed answer.

Retrieval Q&A Chain — RAG without agent unpredictability: retrieval always happens, then one completion grounded in the retrieved chunks. The right default for "chat with my documents".

Memory, in thirty seconds

LLM calls are stateless; memory sub-nodes replay recent exchanges into the prompt. Window Buffer Memory keeps the last N messages per session — the Chat Trigger supplies the session ID automatically. That's all a questionnaire or support assistant needs. Skip memory entirely for one-shot chains: it costs tokens and adds nothing.

Your first AI workflow, in six steps

A concrete starter — an email summarizer you can build in fifteen minutes:

  1. Manual Trigger (you'll wire IMAP later — see automating email triage).
  2. Set node: a text field with a pasted email.
  3. Basic LLM Chain: prompt = "Summarize in one sentence and list requested actions", pass {{ $json.text }}.
  4. OpenAI Chat Model sub-node: gpt-4o-mini, attached via ai_languageModel.
  5. Execute, read the output.
  6. Add a Structured Output Parser ({summary, actions[]}) and re-run: same call, now machine-readable.

Those six steps contain 80% of production AI automation: prepare clean input, prompt precisely, force structure, route on the result.

Mistakes to skip

  • Reaching for an Agent when a Chain suffices — you trade determinism for nothing.
  • Sending raw, unbounded input (whole PDFs, full threads) — truncate; tokens are the cost driver.
  • Parsing free-text model output with string operations — that's the parser's job.
  • One giant system prompt for every case — small, dedicated prompts per task age far better.

From here, the natural next steps are the RAG stack with Supabase or dissecting the 12 documented workflows on this site — each one is a node-by-node annotated example of exactly these patterns.