Memory in Agents: Simple/Postgres Memory, Session Keys, "why does the chat forget"

If an n8n chatbot no longer remembers the user's name or previous questions after the first reply, this is almost always due to the memory configuration of the AI Agent Node and not the language model itself. n8n does not store a conversation history automatically: only when you connect a memory node such as Simple Memory or Postgres Chat Memory to the agent, and this node has a unique session key per conversation, can the agent retrieve previous messages. If the session key is missing, is identical on every run, or the chat trigger is not set to "From Memory", the agent behaves as if every message starts a new conversation. As of: July 2026.

Why the chat "forgets": the most common causes

Before you start tweaking the memory node itself, it is worth looking at the typical sources of error that repeatedly lead to the same symptom in practice.

• No memory node connected: Without a connected memory sub-node, the AI Agent Node has no memory, and every request is processed in isolation.
• Session key is constant or empty: If the session key has the same fixed value on every request, or is missing, all conversations end up in the same memory pool or are not assigned at all.
• Chat trigger not set to "From Memory": According to the n8n documentation on the Chat Trigger Node you must set the "Load Previous Session" option to "From Memory" and connect both the trigger and the agent to the same memory node, otherwise the agent will not load any previous history.
• Simple Memory in queue mode: If you run n8n in queue mode with multiple workers, according to the documentation on the Simple Memory Node you cannot rely on it, because n8n does not guarantee that consecutive calls are processed by the same worker.

The session key: the heart of memory assignment

The session key is the key under which n8n stores a particular conversation in memory. According to the n8n documentation, both Simple Memory and Postgres Chat Memory require exactly this one mandatory parameter to set "the key to use to store the memory in the workflow data" or, in the case of Postgres, in the database table. In practice this means: every conversation needs its own stable value, for example the chat ID from the Chat Trigger, a phone number in telephony scenarios, or a customer ID from your CRM. If you instead use an expression that changes on every run, a new, empty memory is created with every message. A detail that is easily overlooked: sub-nodes such as memory nodes, according to the documentation, always resolve expressions only for the first item, not for each item individually like regular nodes. If you process several chat messages in a batch, this can lead to an incorrect or mixed-up session key.

Simple Memory vs. Postgres Memory: the key difference

Simple Memory, listed in the node list as Window Buffer Memory, keeps the conversation history, according to the documentation, directly in the workflow data of the running n8n instance, making it the fastest way to give an agent any memory at all. The catch: this memory is not permanently bound to a database and, according to n8n, explicitly does not work reliably in a production workflow running in queue mode. Postgres Chat Memory instead writes every message to a table in your own Postgres database, which n8n creates automatically if needed. The history therefore survives restarts, deployments and multiple worker processes. Both node types share the "Context Window Length" parameter, which determines how many previous interactions the agent takes into account as context: too high a value unnecessarily drives up token usage and response time. Important with Postgres: if you connect several Postgres Chat Memory nodes in the same workflow, according to the documentation they access the same memory instance by default. Separate conversations therefore need different session keys, not different nodes.

Connecting the Chat Trigger and Agent correctly

A frequently overlooked step concerns the Chat Trigger Node itself. Only when you switch "Load Previous Session" there from "Off" to "From Memory" does the option to attach a memory node appear at all, and n8n loads the previous history when a session starts. n8n also explicitly recommends connecting the Chat Trigger and the Agent to the same memory node, so that both components use the same source of truth. Otherwise, two separate memory nodes with different session keys create two parallel, inconsistent memories for one and the same conversation, which shows up as erratic or contradictory response behavior.

In practice: when the effort pays off

For an internal test bot or a proof of concept, Simple Memory is usually sufficient. As soon as an agent works productively with real customer data, serves several simultaneous users, or must be traceable in terms of who said what to the agent and when, permanent storage in your own database such as Postgres Chat Memory is the more robust choice, not least because the history can then be exported, checked and deleted there if needed. Anyone who wants to build such an architecture together with a clean session key concept will find a starting point in NordFlux's AI agent services, as well as in general n8n automation.

Frequently asked questions about memory in n8n agents

What exactly is a session key in n8n?

The session key is the identifier under which a memory node stores and retrieves a conversation history. It must be stable and unique per conversation, for example the chat ID from the Chat Trigger, otherwise the agent can no longer match previous messages.

Why is Simple Memory sometimes not enough?

According to the n8n documentation, Simple Memory keeps the history in the workflow data of the running instance and is therefore not bound to a database. In production workflows in queue mode with multiple workers, the node therefore explicitly does not work reliably, because it is not guaranteed that subsequent calls reach the same worker.

Can I use several memory nodes in one workflow?

Yes, but several Postgres Chat Memory nodes, according to the documentation, access the same memory instance by default. For separate conversations you need different session keys, not necessarily different nodes.

Do I need to configure anything extra on the Chat Trigger for memory to work?

Yes. The "Load Previous Session" option must be set to "From Memory", otherwise n8n does not connect the trigger to a memory node and does not load any previous history. In addition, the Chat Trigger and the Agent should be connected to the same memory node.