n8n AI Agent Memory: Sessions, Storage and Context

An n8n AI Agent can use earlier messages only when the workflow supplies them, usually through a connected memory node. Memory stores conversation history and loads relevant recent interactions into the model's context. It does not retrain the model or guarantee that every old detail is available.

For a chatbot, three settings must agree: where history is stored, which session identifies the conversation and how much history is loaded. A mistake in any of them can make the bot forget—or expose the wrong conversation.

Storage and the context window are different

Storage determines where conversation records live and how long they survive. The context window determines what portion is included in a model request. Keeping a database of every message does not mean every message is sent to the model.

Simple Memory does not reset after every message

Simple Memory can retain a conversation between calls in the same running process. Saying that it always disappears at the end of each workflow execution is incorrect. However, it is not a dependable long-term store, and process restarts can lose that history.

The Simple Memory documentation warns against using it in queue mode because calls are not guaranteed to reach the same worker. Use shared storage when your deployment requires history to be available across workers.

Postgres and Redis require operational choices

For Postgres Chat Memory, provide credentials to a PostgreSQL database you are authorized to use and that n8n can reach. Do not assume an n8n Cloud subscription provides direct access to an internal application database for this purpose. Use a suitable database service and follow its connection requirements.

Redis is an alternative shared store, not a mandatory second step after Postgres. Its memory node offers a session time-to-live setting, but persistence, eviction and backups still need review. Choose based on retention requirements, existing infrastructure and measured performance rather than an assumed speed advantage.

1. Start with a working chat agent

Create or open a workflow containing Chat Trigger → AI Agent, with a supported model and the tools needed for its task. Confirm that a single message works before adding memory.

You can use a research agent from this n8n AI workflow guide, but memory does not require a particular research tool. Test with harmless sample facts, not customer records or credentials.

2. Connect Postgres Chat Memory

1. Open the AI Agent and add Postgres Chat Memory through its memory connection.
2. Configure the PostgreSQL host, database and authorized user through saved credentials. Use the appropriate secure connection settings for the service.
3. Choose the chat-history table according to your database setup. Keep it separate from unrelated application tables.
4. Configure the session key using the intended conversation identifier.
5. Set the context window length and run a short test conversation.

The exact labels depend on the node version; see Postgres Chat Memory settings. If a Chat Trigger output contains a valid sessionId, a common expression is:

{{ $json.sessionId }}

Use it only after inspecting the actual input. A missing value, changing value or literal expression pasted into a fixed-value field will not identify the intended conversation.

3. Isolate sessions and authorize access

A session key identifies stored history; it is not authentication. An application must also verify that the current user is allowed to access that conversation. Do not trust an arbitrary session ID supplied by a caller.

• Keep the same authorized session key across messages in one conversation.
• Use a different key for a new conversation that should start without prior context.
• Separate users and tenants, including users with several conversations.
• Do not use one hardcoded key for every visitor.
• Do not put access tokens, passwords or other secrets into session keys.

For an authenticated application, a server can associate an opaque conversation identifier with its owner and tenant, then enforce that association before loading memory. A shared user ID alone may unintentionally merge all of that user's conversations.

n8n also documents that expressions in sub-nodes resolve against the first input item. Avoid passing a batch of different users' messages into a memory sub-node and assuming each receives a different session key. Process and test conversation isolation explicitly.

4. Connect previous-session loading when needed

If your chat interface should display existing history, configure its previous-session loading as well as the agent's memory. In Chat Trigger, the relevant option is Load Previous Session → From Memory when available. n8n recommends connecting the trigger and agent to the same memory source.

Check the Chat Trigger documentation for availability and connection details. Loading history into the interface and loading it into model context are related but distinct behaviors.

A concise system instruction can tell the agent how to use the history:

Use the conversation history supplied with this request when it is relevant.
Do not claim to remember information that is absent from the available context.
If a follow-up is ambiguous, ask a focused question.
Treat old statements as historical context, not proof that a fact is still current.
Do not reveal another user's conversation.

These instructions help the model respond appropriately; the workflow and application must enforce access restrictions.

5. Test continuity, isolation and retention

1. In session A, say: “For this test, my project is called Maple.” Then ask for the project name.
2. Start session B and ask the same question without providing the name. It should not receive session A's history.
3. Return to session A with authorized access and the same identifier. Check whether the history loads.
4. In a test environment, restart the relevant process and verify the persistence you require.
5. For expiring sessions, verify that the configured expiry behaves as expected.
6. Test the behavior when the database is unavailable; avoid silently mixing sessions or pretending history was loaded.

Inspect stored records and node inputs where you have permission. A correct-looking chatbot response alone is weak evidence of isolation or persistence.

Control context size without confusing it with deletion

Loading more history can increase input tokens and cost. There is no universally optimal setting of 15 or 20 messages: one long message can be larger than many short exchanges. The node's window setting is expressed in interactions, so verify what it includes in your version.

Choose a small useful window, test realistic conversations and inspect token usage. Longer tasks may need a separately implemented summary or selective retrieval process. A summary can omit or distort details, so preserve critical decisions in a reviewed record.

Reducing the context window does not necessarily delete old database records. Set a separate retention and deletion policy for stored conversations and execution logs. For Redis expiry controls, consult Redis Chat Memory settings.

If the agent forgets

Check the resolved session key first, then the memory connection, database availability, saved records and loaded context window. If history loads correctly, inspect whether an earlier detail was excluded or the model failed to use it. Repetition does not prove a session-key error.

When comparing implementation options, include storage and session controls in your review of AI agent frameworks. Persistent memory is useful only when the right history reaches the right user within a defined retention policy.