How to Add Long-Term Memory to Your n8n AI Agent (What the Memory Menu Actually Does)

Wire up the memory slot on the n8n AI Agent node, open the chat tester, and it works. Tell it your name, ask it again, it answers. You close the tab feeling like the memory problem is solved.

Then you attach a Schedule trigger. The workflow runs at 6am, and the agent wakes up a stranger. Same node, same workflow, zero recollection of anything it learned yesterday. This is the single most common confusion in n8n agent setups, and it comes from a reasonable misunderstanding: the memory menu looks like a list of long-term memory options. It is not. It is a list of short-term storage backends with one shared limitation.

The memory slot is session-scoped, and sessions are disposable

The AI Agent node takes a sub-node in its Memory slot, connected over the ai_memory input. Every one of those memory nodes keys its stored chat history on a Session ID. Whatever the agent said and heard under session abc123 is only visible to future turns that carry the same abc123.

Here is the trap: when you leave the Session ID at its default, n8n sets it to the execution ID. Every scheduled run is a new execution, so every scheduled run gets a fresh session, so every scheduled run starts with a blank memory. The memory node is working exactly as designed. The design just does not match what a scheduled-automation operator wants.

The menu, decoded

n8n ships eight memory nodes. Grouped by what actually survives, they collapse into three categories:

Node	Backend	What survives
Simple Memory / Window Buffer Memory	in-process memory	Nothing. Lost on n8n restart.
Postgres Chat Memory, Redis Chat Memory, MongoDB Chat Memory	your own database	Chat history across restarts, but still keyed by Session ID
Xata, Zep, Motorhead	managed memory services	Same: durable per-session chat history
Chat Memory Manager	configurable	Explicit get/set control, still session-keyed

The key insight: switching from Simple Memory to Postgres Chat Memory does not give you long-term memory. It gives you the same session-scoped chat log, now written to disk. If each run generates a new session, that log still starts empty every morning. Durable is not the same as long-term. Long-term means accumulated across runs and keyed to the thing that matters (the user, the workflow, the business), and no menu option does that on its own.

There is a second limitation worth knowing: these nodes store raw chat transcripts, not distilled knowledge. The agent remembers the conversation; it does not remember facts learned from the conversation in any structured way. A hundred scheduled runs of full chat history replayed into the prompt is how token bills quietly explode.

Pattern 1: pin the Session ID

If one agent serves one user or one workflow, the cheapest fix is a constant Session ID. Instead of the default execution ID, set the Session ID to something stable like invoice-agent or an expression resolving to the user ({{ $json.userId }}). With Postgres Chat Memory behind it, the agent now accumulates history across runs.

This works well until it does not. The history grows without bound, every old turn gets replayed into every new run, and "memory" is still just a transcript. Fine for a personal assistant with light usage; fragile for a high-volume scheduled automation.

Pattern 2: the read/write fact table

This is what production n8n setups converge on, and it shows up repeatedly in the n8n community forums. Instead of relying on the memory sub-node for anything long-term, you keep a Postgres table with a schema like user_id, key, value, updated_at. The agent reads the relevant rows at the start of each run through a normal Postgres node, and writes updates back at the end, either directly or through a dedicated save tool.

The appeal is control: you decide exactly what persists, you can inspect and edit the table like any other data, and the agent only receives facts, not hundred-turn transcripts. The cost is maintenance. You own the schema, the prompt discipline that makes the agent actually save and retrieve, and the hygiene of deleting stale rows. For teams already running Postgres, this is usually the right default.

Pattern 3: a hosted memory layer over MCP

n8n ships an MCP Client node, which lets the AI Agent consume any external MCP server as a tool provider. That opens a third option: keep the memory outside n8n entirely, behind a managed API, and let the agent read and write it through MCP tools.

This is the lane Vilix AI is built for. It is cloud-hosted, so there is no database or memory server to run. The same memory is reachable over MCP from every connected tool, which means the n8n agent, Claude, Codex, and Cursor can all read and update one shared store instead of each keeping a private amnesiac copy. It stores full conversation history, not just extracted facts, alongside rules, tasks, and reusable agent skills, and retrieval is semantic plus keyword, so the agent gets the relevant context rather than a full log dump. There is a free plan forever and a 7-day Pro trial that needs no credit card, and you can export everything or delete the account and its data at any time.

The honest tradeoff: it is a managed cloud service, so memory lives outside your own database. If your policy requires every byte on your own infrastructure, Pattern 2 is the better fit. If you would rather not own another database, the API route removes an entire category of maintenance.

Which pattern should you pick?

• Chat tester or demo only: Simple Memory is fine. It was built for this.
• One recurring workflow, one user: pinned Session ID plus Postgres Chat Memory. Ten minutes of work, and the amnesia stops.
• Multiple users, multiple agents, or real volume: the read/write fact table. More setup, full control, no transcript bloat.
• Memory that should follow you across n8n and every other AI tool you use: a hosted memory layer over MCP, because the memory outlives any single workflow.

The n8n memory menu is a good toolkit once you know what it is: session-scoped storage backends, not long-term memory systems. Long-term memory is a design decision you make one layer above the menu, and now you know the three designs that actually work.