The agent you built responds well, but every new message is treated like a first introduction. The name mentioned a minute ago disappears, the context of previous questions is not carried over, and the answers feel smart yet forgetful. Almost always, this is not about the language model being less sophisticated, but rather about memory that has not been installed or has been installed with the wrong key.
Chains have no memory, only agents do
The first check is often overlooked: in n8n, the AI Agent node can use memory, whereas the AI Chain cannot. If your flow is built with a chain, there are no settings that will make it remember. Memory is also not a built-in feature of the agent, but rather a separate sub-node that needs to be added manually.
Session key: a separator between speakers, not just a name
Memory is stored per session key. If the trigger is the built-in chat node, the sessionId is taken automatically. Once the trigger is changed to Telegram, WhatsApp, or a webhook, that key is no longer available, and n8n throws an error No sessionId. This is where the key must be filled in manually with something that truly distinguishes one person from another, such as a Telegram chat ID or a WhatsApp sender number.
The two most common mistakes occur in opposite directions, and neither generates an error:
- The key changes with each execution, causing each message to open a new session and the agent appears forgetful.
- The key is constant for everyone, so all users share one history. This not only leads to chaotic answers but also allows one user's conversation to be read by another user.
The n8n documentation states that static keys like my_test_session are only for testing and requests proper session management to be set up before the flow is published.
Sub-node trap: expressions always fall to the first item
This behavior is different from regular nodes and is easily overlooked. In general nodes, expressions are resolved for each item in turn. In sub-nodes, including memory nodes, expressions always yield the first item. So if the session key is filled with an expression while the node processes five items simultaneously, all five will use the key belonging to the first item.
One flow, one memory
If there is more than one memory node in the same flow, they all access the same memory instance by default. To truly separate them, the session ID in each node must be differentiated. This is important before executing actions that overwrite the memory contents, such as the override all messages operation on the Chat Memory Manager node.
Context Window Length: forgetting that is intentional
This parameter determines how many previous interactions are taken into account. Since it is a window, the oldest conversation turns automatically drops out as a new one comes in. If the agent remembers the last five minutes but forgets the beginning of the conversation, that is normal window behavior, not a malfunction.
Simple Memory stops working once in queue mode
This is the limitation that often bites when the flow goes into production. The n8n documentation states that Simple Memory does not work on active production flows when the instance runs in queue mode, as n8n cannot guarantee that each memory call goes to the same worker.
The reason lies in how queue mode operates: the main instance only creates executions, its ID is stored in Redis as a queue, and then any available worker picks it up. Each worker is a separate Node.js process, and one worker can run multiple executions simultaneously, with a default concurrency value of 10.
For production, move the storage outside the process. Postgres Chat Memory uses three parameters: Session Key, Table Name (which is created automatically if it does not exist), and Context Window Length. Other options provided by n8n include Redis, MongoDB, Motorhead, Xata, and Zep.
Order of checks when the agent appears forgetful
- The node used by the agent or chain.
- Whether the memory sub-node is installed or not.
- The source of the session key, automatically from the chat trigger or filled in manually.
- That key is truly unique per user, not constant and not changing with each execution.
- The Context Window Length value is sufficient for the expected length of the conversation.
- The instance is running in queue mode or not.
How to set up memory and fill in the session key is also demonstrated directly in the N8N and AI Integration class for Building Smart Workflow & AI Agent with Kristian Ekachandra. If you prefer to see the steps executed, there's a clip here.