n8n AI Agent Memory: Which Memory Node to Use

The best memory for an n8n AI Agent depends on where the workflow runs. Simple Memory (once called Window Buffer Memory) is fine for testing. For production, use Postgres Chat Memory or Redis Chat Memory, which survive restarts and queue mode. None of these remember facts across conversations, so long-term memory needs an external system.

This page covers each n8n memory node, how session IDs work, how to clear memory, and how to add long-term memory. Node names and options come from the n8n docs and the n8n source code.

What is n8n AI Agent memory?

n8n AI Agent memory is a sub-node that stores the chat history of a conversation and passes recent turns back to the AI Agent node on each run. Without it, every message reaches the model with no context. The memory node decides where the history lives (n8n’s process, Postgres, Redis, MongoDB) and how many past turns the model sees.

Only agents can use it. The n8n docs state plainly that “AI agent nodes can use memory, but AI chains can’t.” So if you need conversation history, build the flow around the AI Agent node, not the Basic LLM Chain.

Every chat memory node is a form of short-term memory for AI agents: it replays recent messages. It doesn’t extract facts, merge them, or search old conversations by meaning.

The n8n memory nodes compared

These are the memory sub-nodes in the n8n integrations docs and source code, with their main settings.

The deprecation notes come from n8n’s deprecated nodes list, which says deprecated nodes get no more updates or fixes. Existing workflows keep running.

Simple Memory (Window Buffer Memory)

Simple Memory keeps chat history inside the running n8n process. The node description in the source reads “Stores in n8n memory, so no credentials required.” Older templates call it Window Buffer Memory; n8n’s AI Agent troubleshooting page says to delete and re-add the node if an old version throws errors.

Three limits matter:

1. It breaks in queue mode. The docs warn not to use it if n8n runs in queue mode, because “n8n can’t guarantee that every call to Simple Memory will go to the same worker.”
2. It’s not durable. History sits in an in-memory map. A restart wipes it.
3. Idle sessions expire. In the current source, buffers not accessed for one hour are cleared on the next memory call.

The source also prefixes each session key with the workflow ID. Two different workflows using the same session ID won’t share Simple Memory history.

Postgres, Redis and MongoDB chat memory

These three nodes store history in a database you run, so it survives restarts and works across queue-mode workers.

Postgres Chat Memory creates its table if it doesn’t exist. The underlying LangChain store writes one row per message with id, session_id and message columns. Redis Chat Memory stores each session as a Redis list and adds a Session Time To Live in seconds, so idle chats expire on their own. The default is 0, meaning no expiry. MongoDB Chat Memory lets you pick the database and collection.

Databricks Lakebase Chat Memory (new)

n8n added a Databricks Lakebase Chat Memory sub-node on October 19, 2026 (PR #41055). It first shipped in n8n 2.45.0, a beta (pre-release) published October 20; the stable release published October 21 is 2.44.5, which doesn’t have it (its memory folder has no Lakebase node), so you need the beta channel until 2.45 goes stable. It stores history in a Lakebase table through Databricks’ Data API and logs in with Databricks OAuth2.

It differs from Postgres Chat Memory in three ways, all from the node’s source:

1. It can’t create its table. The node tells you to run a CREATE TABLE in the Databricks SQL editor first. A run against a missing table shows the exact SQL and the GRANT statements for your role.
2. Messages are stored the same way. Each row has id, session_id and a JSONB message, like the Postgres store, and the default table name is the same n8n_chat_histories.
3. Very long sessions fail on purpose. It reads history in pages up to a fixed cap. If a session holds more rows than that, it stops with an error and tells you to clear the session, rather than silently dropping old turns.

Pick it only if your data already lives in Databricks. Otherwise, Postgres Chat Memory does the same job with less setup.

What Context Window Length does

Context Window Length is the number of past interactions the model receives. The default is 5. Under the hood it’s LangChain’s BufferWindowMemory, which returns the last k * 2 messages, so 5 means the last five user and AI exchanges (10 messages).

The database nodes still store the full history. The window only limits what goes into the prompt. A long window raises token cost on every call.

How session IDs work in n8n memory

The session ID decides which conversation a message belongs to. Get it wrong and users see each other’s history, or every message starts fresh. Current versions of the memory nodes offer a Session ID option with two choices:

With Define below, use a stable per-user value, for example {{ $json.message.chat.id }} from a Telegram trigger. If n8n can’t find a session ID, it throws “No session ID found”, and the error tells you to change the Session ID parameter. The docs suggest a static key such as my_test_session only for testing.

Sharing history between nodes takes care. The docs warn that several memory nodes of the same type use the same memory instance by default. In recent node versions, n8n’s editor shows a different hint: with Connected Chat Trigger Node, the session is scoped to that one memory node, and to share it you switch to Define below and use the same key in each node. If two agents must read the same history, set the key explicitly in both.

Langflow, the other common low-code builder, has the same trap in a different form: its default session ID is the flow ID, so every user of a flow shares one history until you pass a per-user ID. The Langflow memory chatbot guide covers that and the gateway header Langflow 1.12 added for it. In Dify, memory follows the conversation_id your client sends back, and single-turn Workflow apps keep none; agent sessions in Dify 1.18 also can’t survive a rollback to an older version (Dify LLM memory).

How to clear n8n AI Agent memory

n8n has a node for this: Chat Memory Manager. Attach it to the same memory sub-node (and session) the agent uses.

1. Add a Chat Memory Manager node where the reset should happen, for example after a “/reset” command.
2. Connect the same memory sub-node type the agent uses, with the same session key.
3. Set Operation Mode to Delete Messages.
4. Set Delete Mode to All Messages to wipe the session, or Last N with a Messages Count to drop recent turns.
5. To replace history instead, use Insert Messages with Override All Messages.
6. Use Get Many Messages with Simplify Output to check what’s stored.

Outside n8n, you can clear the store directly. For Postgres, delete the session’s rows. For Redis, delete the key, which is the session ID itself. This Python script does both:

 1import psycopg
 2import redis
 3
 4SESSION_ID = "user-42"
 5
 6# Postgres Chat Memory (default table name)
 7with psycopg.connect("postgresql://n8n:secret@localhost:5432/n8n") as conn:
 8    conn.execute(
 9        "DELETE FROM n8n_chat_histories WHERE session_id = %s", (SESSION_ID,)
10    )
11
12# Redis Chat Memory: each session is a list stored under the session ID
13redis.Redis(host="localhost", port=6379).delete(SESSION_ID)

For Simple Memory, there’s no table to clear. Use Chat Memory Manager, switch to a new session ID, or wait for the one-hour idle cleanup. A restart also clears it.

Long-term memory for n8n agents

Chat memory nodes replay recent messages. They don’t remember that a user said “I’m vegetarian” three weeks and two sessions ago, unless that message still sits in the window. For that, you need persistent memory across sessions: a system that extracts facts, stores them, and retrieves the relevant ones by meaning.

There are four practical routes in n8n:

Memory servers you can reach from n8n

Hindsight is an open-source (MIT) agent memory system. It ships an n8n community node, @vectorize-io/n8n-nodes-hindsight, with three operations: Retain (store content in a memory bank), Recall (search a bank) and Reflect (an LLM-written answer over the bank). It’s a regular workflow node, so the usual pattern is Recall before the agent and Retain after. Every Hindsight server also exposes an MCP endpoint per bank at /mcp/{bank_id}/, which the MCP Client Tool can call. Where it earns its place is an agent that talks to the same users for months: it consolidates facts into observations, and on the long-history BEAM test it scores 73.9 at 1M tokens versus Mem0’s 64.1 (Mem0’s comparison, vendor-run). It self-hosts free from one Docker container, like many n8n instances, and works with 25+ LLM providers including local Ollama. The Hindsight README itself notes that it “may be overkill” for simple n8n workflows, and each Retain makes LLM calls.

Zep dropped out of the built-in node list: the Zep memory and vector store nodes are deprecated. Zep Cloud still has a REST API you can call from the HTTP Request node. See what Zep memory is for its current product.

Other memory servers with MCP endpoints include Supermemory (hosted at https://mcp.supermemory.ai/mcp) and Graphiti, whose repo includes an MCP server. For more options, see the list of AI memory MCP servers.

Which n8n memory should you pick?

• Building or testing a workflow: Simple Memory. No setup.
• Production chatbot on one instance or queue mode: Postgres Chat Memory. Durable, easy to inspect and clear with SQL.
• High-traffic chat where old sessions should expire: Redis Chat Memory with a Session Time To Live.
• Already on MongoDB: MongoDB Chat Memory.
• Agent must remember facts across sessions: keep a chat memory node for recent turns, and add an external memory system for long-term facts.
• Assistant that serves the same users for months, or should reason over what it knows: Hindsight’s community node, with Recall before the agent and Retain after. Skip it for one-off automations.
• Workflows on Zep or Motorhead nodes: plan a migration; both are deprecated.

For the wider picture of memory types and tools beyond n8n, see AI agent memory explained.