n8n AI Agent memory: session keys, stores and durable context

Does the n8n AI Agent remember between runs?

Only when you connect a memory sub-node. The AI Agent node accepts a memory input, and the memory node stores chat history under a Session Key. The next execution can load that history and pass the recent messages to the model. Without a memory node, each execution starts without the previous conversation.

n8n documents an important boundary: AI agent nodes can use memory, but AI chains cannot. Memory is also short-term conversation context. It does not automatically extract durable facts, merge conflicting preferences or delete a customer’s history from every derived copy.

What does Simple Memory store, and when should you avoid it?

Simple Memory persists chat history in the workflow data. It has two important parameters: the Session Key that selects the conversation and the Context Window Length that limits how many previous interactions enter the prompt. It is the fastest way to prototype a chat loop in a single n8n instance.

The current documentation warns that Simple Memory does not work in queue mode because n8n cannot guarantee that every call reaches the same worker. Use Postgres Chat Memory or Redis Chat Memory for production workflows that run across workers or restarts.

• Use Simple Memory for local prototypes and single-process workflows.
• Do not use it for queue-mode production workflows.
• Use a unique Session Key per user or conversation.
• Keep the Context Window Length small enough for the model budget.
• Remember that workflow data is not a durable customer memory system.

Which n8n memory store should you use?

Postgres Chat Memory stores messages in a database table and creates the table when it does not exist. Redis Chat Memory stores them in Redis and supports a Session Time To Live. Both accept a Session Key and a Context Window Length. MongoDB and other memory nodes follow the same pattern.

Multiple memory nodes in one workflow access the same memory instance by default. That is convenient until two agents or two conversations share the same key. Use different Session Keys when you need separate memory instances, and test the result with two users who have similar names.

How does the n8n Session Key work?

The Session Key selects which conversation the memory node reads and writes. A Chat Trigger usually produces a session identifier, but production workflows should derive the key from trusted application context such as the authenticated user and the conversation or ticket. A constant key is the fastest way to mix every user into one conversation.

Treat the key as a lookup value, not as an authorization token. Validate the user and tenant before the memory node runs. If the key contains a tenant prefix, check that the caller actually belongs to that tenant rather than trusting the string.

{{ $json.tenantId }}:{{ $json.userId }}:{{ $json.threadId }}

How do you add long-term memory to an n8n workflow?

Use the memory node for the live conversation and an external memory service for durable facts. An HTTP Request tool can call a memory API with the authenticated user, tenant and source event, then retrieve a small set of relevant facts before the agent answers. An MCP Client Tool can expose the same operations through a memory MCP server.

Write after a meaningful outcome, not after every message. Store the accepted plan, the customer preference, the failed workaround or the escalation rule, with provenance and a validity state. When a later workflow corrects the fact, supersede the old record instead of appending a contradiction.

{
  "text": "Customer prefers email follow-up for billing issues.",
  "user_id": "{{ $json.userId }}",
  "metadata": {
    "tenant": "{{ $json.tenantId }}",
    "source": "support-thread-4821",
    "kind": "preference"
  }
}

How do you keep n8n memory isolated per user and tenant?

Use the tenant as the outer boundary and a user or conversation key inside it. Store the same scope with the external memory record, not only in the Session Key. When the workflow retrieves facts, filter by the authenticated tenant and user before the model sees the result.

Do not rely on the model to choose the tenant, and do not let one workflow reuse a memory table across tenants without a scope column. If a shared Postgres table serves several products, enforce the scope in the query and add a test that a similar user in another tenant receives no records.

• Derive the tenant from the authenticated workflow context.
• Use a per-user or per-thread Session Key, never a global constant.
• Filter external memory by tenant and user at read time.
• Use separate memory tables or schemas when policy requires it.
• Test a wrong-tenant request with a semantically similar user.
• Delete by user or tenant when the account closes.

What are the limits of n8n AI Agent memory?

A memory node is a chat-history store. It does not know which facts are true, which preference is current or which message must be deleted for legal reasons. It also does not automatically share memory across separate workflows, agents or products unless they use the same external store and key.

Context Window Length is a prompt budget, not a retention policy. Dropping older messages from the prompt does not delete them from Postgres or Redis. A workflow that writes every message can grow storage and cost without improving recall. Store the conversation for continuity and promote durable facts deliberately.

• Chat history is not a corrected fact store.
• Simple Memory is not queue-mode safe.
• Multiple memory nodes share an instance by default.
• Context Window Length does not delete stored messages.
• Workflow-scoped memory does not follow the user to another workflow.
• A Session Key is not an authorization grant.

How do you test n8n AI Agent memory?

Test the memory node and the workflow together. Start two conversations with different Session Keys and verify that each agent sees only its own history. Restart the worker or switch to queue mode and confirm that Postgres or Redis still returns the expected messages. Then change a stored fact and verify that the next answer uses the new value.

Test the external memory path separately: write a fact, retrieve it in a new execution, correct it and delete the user. Confirm that the memory node and the external service do not return a stale copy after deletion.

What is the recommended n8n memory architecture?

Use Postgres or Redis Chat Memory for production conversation continuity, with a Session Key derived from the authenticated tenant, user and thread. Use Simple Memory only for local prototypes. Add an external memory API or a memory MCP server when facts must survive across workflows, agents or products, and keep correction, retention and deletion in that governed layer.