Giving an n8n AI agent long-term memory (Postgres, vector store)

An n8n AI agent fitted with a Window Buffer Memory holds a decent conversation for ten exchanges, then forgets. It also forgets everything when the instance restarts, and it never knew who yesterday's user was. For a throwaway chatbot, that's acceptable; for a support assistant following customers over time, it's a deal-breaker. This article complements our guide to conversation memory for an AI agent — which covers short session memory — by tackling the layer above: persisting the history in PostgreSQL and building long-term semantic memory in a vector store. Along with the purging and GDPR questions that persistence makes unavoidable.

What the Window Buffer Memory cannot do

The Simple Memory node (Window Buffer Memory) connected to an AI Agent node replays the session's last N exchanges into the model's context. Two structural limits:

• Volatile: the history lives in the n8n process's memory. Restart, upgrade, crash — everything is lost, with no error or warning. The agent simply starts from scratch.
• Bounded: the window keeps N exchanges, full stop. At the eleventh message of a ten-exchange window, the first exchange drops out of the context. Whatever the user explained at the start of a long conversation no longer exists for the agent.

These limits are a design choice, not a flaw: the sliding window keeps the context short and the per-call cost predictable. The problem isn't the window — it's having only the window.

That observation is exactly the starting point of the 2023 study by Packer et al., "MemGPT: Towards LLMs as Operating Systems" (Google Scholar): since an LLM's context window is structurally limited, the authors propose treating it like an operating system's RAM — a scarce resource into and out of which a management mechanism moves information from external storage, exactly the way an OS pages between RAM and disk. That's the architecture we reproduce in practice with n8n: a short context handled by session memory, backed by persistent storage queried on demand.

Step 1 — Persist the history with Postgres Chat Memory

The simplest replacement for the Window Buffer is the Postgres Chat Memory node: connected to the agent's same Memory input, it writes every exchange to a PostgreSQL table and reloads the session's history on each run. Concretely:

• The history survives restarts: the agent picks a conversation back up where it left off, even after an instance upgrade.
• The history is inspectable: a simple SQL query shows what the agent saw — invaluable when debugging a strange answer.
• The database can be the same PostgreSQL instance n8n uses, or a dedicated one — for example your Supabase project, whose connection is covered in our guide to connecting n8n to Supabase.

The decisive choice: the session key

The most important parameter isn't the database connection — it's the Session Key: the identifier that groups messages belonging to the same conversation. A few proven choices by channel:

• Telegram / WhatsApp chatbot: the incoming message's chat_id — stable, unique per user, provided by the platform.
• Email assistant: the sender's address, possibly normalized (lowercased, aliases stripped).
• Internal application: your authentication system's user id, passed in the webhook payload.

Two classic mistakes: a key that's too broad (a shared channel id) makes the agent read everyone's conversations blended together; an unstable key (an execution id, a timestamp) creates a fresh session on every message, which amounts to having no memory at all. Explicitly test the "two users writing at the same time" case before going to production.

Step 2 — Semantic memory: facts, not transcripts

Persisting the history isn't enough: replaying six months of conversations into the context is impossible, and the essentials would drown in it anyway. The second layer stores distilled facts — preferences, context, decisions — and recalls only the relevant ones. That's precisely the mechanism validated by Park et al. in "Generative Agents: Interactive Simulacra of Human Behavior" (Google Scholar), presented at UIST 2023: their agents record their experiences in a persistent memory stream, then retrieve at decision time the memories ranked highest by relevance, recency and importance — and ablating that memory markedly degrades the believability of their behavior.

Transposed into n8n with Supabase and pgvector:

• Writing: at the end of a conversation (or when a notable fact is detected), an LLM node extracts durable facts — "prefers to be contacted in the morning", "on the Pro plan since 2024", "already reported bug X" — then each fact is embedded via an embeddings node and inserted into a pgvector table with the user identifier and a timestamp.
• Recall: at the start of every new conversation, a similarity search between the incoming message and that user's facts surfaces the 3 to 5 most relevant, injected into the system message ("Known context about this user: …"). A more agentic alternative: expose the search as a tool the agent calls when it needs it, following the pattern of our custom tools.

The embeddings + pgvector + similarity search machinery is the same as for document RAG — our RAG guide with n8n and Supabase walks through it step by step, and the RAG chatbot with citations workflow shows a complete implementation. The difference is what gets indexed: per-user facts rather than shared documents.

Two safeguards on the write side: deduplicate (check by similarity that an equivalent fact doesn't already exist) and timestamp so contradictions can be arbitrated — a recent fact wins over an old one.

Purging and GDPR: memory is personal data

As soon as the memory contains personal data — and a conversation history almost always does — it falls under GDPR. Three obligations to wire in from the design stage:

• Storage limitation: a scheduled purge (a Schedule Trigger and a DELETE query on rows older than your retention period) rather than indefinite accumulation.
• Right to erasure: being able to delete every row — history and vectorized facts — tied to a given session key. Our guide on handling GDPR requests with n8n shows how to industrialize that kind of request.
• Minimization: don't store sensitive data among memorized facts; the LLM extraction should be instructed to ignore health, opinions and banking details.

One point that's often missed: distilled facts are personal data just as much as transcripts are. The purge must cover both tables.

When not to give an agent long-term memory

Persistent memory has a cost — infrastructure, complexity, GDPR surface — that isn't always justified:

• One-off interactions: a qualification form, an FAQ, a document-processing task have nothing to remember from one run to the next.
• Context already available elsewhere: if your CRM already holds the customer history, a tool that queries it live beats a vectorized copy that drifts out of sync.
• Risk of wrong memorization: a badly extracted fact ("prefers annual billing" inferred from a question) will resurface with the confidence of a certainty. On high-stakes topics, no memory beats false memory.

The sensible progression: Window Buffer for prototyping, Postgres Chat Memory as soon as the agent touches real users, semantic memory only once a concrete need for cross-session personalization has been demonstrated.

Putting it into practice

The complete architecture — agent, session memory, a Supabase vector store queried by similarity — is exactly what the RAG Assistant Pack (€119) ships: the included workflows provide the embeddings, pgvector storage and recall layers, which you only need to point at user facts rather than documents to get the long-term memory described here. Combined with conversation memory for the short thread and a scheduled GDPR purge, the agent gains what most chatbots lack: the ability to remember the right thing, at the right time, without keeping everything else.