How to persist user session data for an AI agent across executions in n8n?

The most reliable way to persist user session data for an AI agent across n8n executions is to store that session state in an external data store (like a database, Redis, or even n8n’s own built‑in Data Store), and then read/update that record at the start and end of each workflow execution. n8n itself does not preserve state between runs, so you must persist it somewhere external.

 

Why this is the correct approach

 

n8n workflows are stateless. This means that each run starts fresh, with no memory of previous runs. Nodes don’t “remember” anything unless you explicitly save it somewhere. For an AI agent, a “session” usually means keeping past messages, user profile, intermediate reasoning steps, or context needed for the next turn. Since n8n clears all of that at the end of an execution, you must persist it.

The external data store then becomes your agent’s memory. n8n becomes the orchestrator that reads it, updates it, and writes it back.

 

Practical, production‑ready pattern

 

• At the beginning of the workflow (e.g., after a Webhook Trigger), you look up the user session by a user ID, session ID, email, or whatever uniquely identifies the user.
• If the session exists, you load it into the workflow as JSON. If it doesn't, you create a new empty state.
• Run your AI logic with the stored state as context.
• After producing the assistant response, you update the stored session record with the new message or updated agent state.

This works regardless of whether your sessions last minutes or weeks. n8n just reads and writes your session like any other data record.

 

Option A: Use n8n Data Stores (simple, built‑in)

 

n8n Data Stores are a lightweight key‑value storage built directly into n8n (Cloud and Self‑Hosted). They are easy to set up and reliable for moderate volumes. Good for prototypes and many production cases.

• Create a Data Store in n8n
• Use its ID as your storage location
• Use the Data Store Get node at workflow start
• Use the Data Store Update / Set node after generating a message

For example, your Data Store entry might have a key like user\_123 and the value being the session JSON.

 

Option B: Use a database (PostgreSQL / MySQL / MongoDB)

 

This is the strongest production option when you expect many users, heavy querying, long histories, or need reliability across deployments.

• Store each session in a row or document
• Use credentials in n8n to connect securely
• Use Postgres, MySQL, or MongoDB nodes to read and write state

Sessions become durable and auditable, and you can expire, archive, or search them as needed.

 

Option C: Redis (fast, great for short‑lived sessions)

 

Redis works well for agent‑style memory that doesn’t need permanent history. It’s extremely fast and lets you set TTLs (time‑to‑live) so sessions expire automatically.

n8n has a Redis node that lets you:

• Get a session key like session:user\_123
• Set or update it
• Apply expiration times

 

Minimal working example using a Data Store

 

This simulates the core logic: load session, append the new message, save it back.

// Example of transforming session data inside an n8n Function node

const userId = $json.userId;
const incomingMessage = $json.message;

const previousSession = $json.session || { history: [] }; // loaded from Data Store earlier

// Append the new message
previousSession.history.push({
  from: "user",
  text: incomingMessage,
  timestamp: new Date().toISOString()
});

// Return new session content for saving
return {
  userId,
  session: previousSession
};

This output becomes the input to a Data Store Update node.

 

How the workflow usually looks in real production

 

• Webhook Trigger receives: user\_id, message
• Data Store Get fetches session JSON
• Function node merges message into session
• AI Model node generates a response using the session as context
• Function node updates session memory with assistant message
• Data Store Update saves the updated session
• Respond to user

This pattern ensures that every conversation turn has continuity, even though n8n itself does not persist state across runs.

 

Important production notes

 

• Never store session in globals or environment variables. They won’t persist across executions.
• Always guard for missing sessions. New users should auto‑create an empty state.
• Use IDs, not tokens, as keys. Avoid exposing session keys via webhook URLs.
• Be mindful of size limits. Don’t store huge chat histories; prune or summarize if needed.

 

So the short version is: n8n cannot hold session state by itself, so you must store it externally — Data Store, database, or Redis — and load/update it every time. That’s the pattern used in real, production AI agent workflows.