An n8n AI agent starts every execution with a blank slate. Short-term memory fixes that within a conversation: a chat memory sub-node stores the last few messages under a session ID and hands them back to the model on the next turn. Long-term memory is different. It means storing facts, summaries or documents in a database (Postgres, Redis or a vector store) and retrieving the relevant parts when a returning user writes again, days or months later.
Most production agents need both: a short window of recent messages for the conversation, and a deliberate long-term store for what should be remembered. This post explains the options in n8n and how we choose between them.
Why do n8n AI agents forget?
Because every workflow execution is independent, and language models have no memory of their own. Unless the workflow passes earlier messages back in, the model sees only the current one. Even when you do pass history, the model’s context window is finite: send too much and you pay for tokens on every turn, slow the agent down, and eventually hit the limit.
So memory is a design decision about what to keep, for how long, and what to send to the model each time.
What memory options does n8n have?
The AI Agent node accepts a memory sub-node. The main options:
| Option | Where messages live | Survives a restart? | Good for |
|---|---|---|---|
| Simple Memory (formerly Window Buffer Memory) | Inside the n8n instance | No | Prototypes and single-instance setups |
| Redis Chat Memory | Redis | Yes, with a TTL if you set one | Fast session memory for chat and WhatsApp bots |
| Postgres Chat Memory | A Postgres table | Yes | Durable history you can query and audit |
| MongoDB Chat Memory | MongoDB | Yes | Teams already on MongoDB |
| Vector store as a tool (Pinecone, Qdrant, Supabase, PGVector and others) | A vector database | Yes | Long-term recall of documents and past conversations by meaning |
The Chat Memory Manager node lets a workflow read, insert or clear messages in a memory store outside the agent, which is useful for summaries and clean-up jobs. Node names change between n8n versions, so check the current docs for your instance.
How does short-term memory work in n8n?
Two settings matter:
- Session ID. The key under which messages are stored. The Chat Trigger provides one automatically; for other channels, use something stable and unique such as the WhatsApp number or the CRM contact ID. Get this wrong and two customers share one conversation history.
- Context window length. How many recent interactions are sent to the model. A handful is enough for most support and qualification bots; more costs tokens on every turn.
Simple Memory keeps messages in the n8n process. It disappears on restart and isn’t shared between workers, so don’t use it if n8n runs in queue mode or across several instances. Use Redis or Postgres there.
How do you give an n8n agent long-term memory?
There are three patterns, and they combine well:
- Persistent chat history. Postgres Chat Memory keyed by a customer ID keeps the full history. The agent still sees only the last few messages, but the record is there for audits and for the next two patterns.
- A rolling summary or fact sheet. A separate step asks a model to summarize the conversation, or to extract facts worth keeping (plan, open issue, preferred language), and writes them to a table. The next conversation loads that summary into the system prompt. This is how you get a “summary buffer” in n8n: the built-in chat memory stores raw messages, and the summarizing is a step you add.
- Retrieval (RAG). Documents, past tickets or long histories are split into chunks, embedded and stored in a vector database. The agent gets a vector-store tool and retrieves only the passages relevant to the current question. This is the closest thing to “unlimited” memory, but it remembers by similarity, not by certainty, so it needs testing. Our post on using RAG to stop AI hallucinations covers how we check it.
Which memory should you choose?
| Need | Use | Cost |
|---|---|---|
| Remember the last few turns of one chat | Simple Memory (single instance) or Redis Chat Memory | Low: tokens for the window only |
| Remember a customer across sessions | Postgres Chat Memory plus a stored summary or fact sheet | Moderate: extra model call to summarize |
| Answer from a large knowledge base or long history | Vector store retrieval | Higher: embeddings, storage and retrieval calls |
| Coordinate several agents | A shared Postgres table both agents read and write, not a shared chat window | Depends on design |
Start with the simplest option that works and add a long-term store only when users actually return and expect to be remembered. For multi-agent setups, see multi-agent orchestration in n8n, and for when n8n’s built-in agent tooling stops being enough, LangChain vs n8n.
What goes wrong with AI memory in production?
- Session collisions. A generic or missing session ID mixes customers’ histories. Test with two users at once before launch.
- Unbounded growth. Without a window limit, retention policy or TTL, history grows and every call gets more expensive.
- Stale facts. A stored summary says the customer is on the Basic plan after they upgraded. Facts that change should be read from the CRM, not from memory.
- Personal data. Memory is a database of what customers told you. It needs a retention period, deletion on request and access controls, like any other personal data store.
- Memory poisoning. A user can tell the agent something false or an instruction to store. Keep what the agent may write to long-term memory narrow and structured.
In the agents we build, one rule covers most of these risks: the agent writes to a review queue, and nothing reaches a customer or a CRM record until a person approves it. We explain why in human-in-the-loop AI automation.
FAQ
What is the difference between memory and RAG in n8n?
Chat memory stores the conversation itself and sends recent messages back to the model. RAG retrieves relevant passages from a separate knowledge store. Memory is about continuity; RAG is about knowledge. Long-term memory often uses RAG over past conversations.
Does Simple Memory survive an n8n restart?
No. It lives in the running n8n process. Use Redis or Postgres chat memory for anything in production.
Is there such a thing as infinite memory for AI agents?
Not really. “Infinite memory” usually means a long-term store with retrieval: everything is saved, and only the relevant parts are fetched for each turn. The model still sees a limited context.
Can two n8n agents share memory?
They can read the same Postgres table or vector store. Sharing one chat window between agents usually confuses both; a shared table of structured facts works better.
Our AI and automation team builds n8n agents with memory, retrieval and a human approval step; get in touch if you are planning one.
