n8n AI Agent Session ID Memory, Explained: Why Your Agent Forgets Everything Between Runs

If you have ever built an AI agent in n8n, hooked it to a schedule trigger, watched it run beautifully on Monday, and then watched it stare blankly at Tuesday's run with zero memory of Monday, this post is for you.

The usual suspect is not your prompt. It is not the model. It is a small parameter on the memory node called the session ID, and it is doing exactly what you told it to do, which is not what you wanted.

The one-sentence version

n8n's memory nodes store conversation history indexed by a session key. Messages that share a session key share memory. Everything else is a stranger.

That is the whole mechanism. Once you see it, most "memory bugs" stop being mysterious.

What the session ID actually does

Every memory node in n8n (Simple Memory, Window Buffer Memory, Postgres Memory, Redis Memory) keeps a list of messages per session. The session key is the lookup column. When your AI Agent node runs, it hands the memory node a session key, and the memory node hands back the history filed under that key.

Use the chat trigger and n8n generates a session ID per conversation. A WhatsApp bot keyed on the sender's phone number remembers each person separately. That part works nicely.

Use a schedule trigger and things get quieter. Scheduled runs have no chat session. So what does the memory node use as its session key? Often the default: the n8n execution ID.

The default trap: every run gets amnesia

The execution ID is unique per run. That is its entire job. So when the memory node keys on it, Monday's 6am run writes its history under Monday's execution ID, and Tuesday's 6am run asks for Tuesday's execution ID, finds nothing, and starts from zero.

Your agent is not broken. It remembers perfectly. It just never gets asked about the same session twice.

In my experience this is the single most common reason a scheduled n8n agent "forgets everything between runs." The fix is one parameter: give the session key a stable value.

Pick your pattern

There are really only three patterns, and you should pick one on purpose:

1. Per-user memory (chat agents). Session key = the user's stable identifier. Phone number for WhatsApp, chat session ID for the webchat trigger, CRM contact ID for a support flow. Everyone gets their own thread and nobody reads anyone else's history.

2. Per-workflow memory (scheduled agents). Session key = a fixed string like daily-standup or the workflow name. Every run reads and writes the same thread, so the agent picks up where the last run left off. This is the one people miss.

3. Per-execution isolation (deliberate amnesia). Session key = the execution ID. Each run starts clean on purpose. Useful for stateless classifiers and one-shot graders, anywhere yesterday's context would contaminate today's judgment.

The third pattern is a feature, not a bug, when you choose it. The pain only comes when it happens by default and you never notice.

The gotchas nobody warns you about

A few more things that bite once the session key is sorted:

Simple Memory is not durable. It lives in memory on your n8n server. Restart the container and the threads are gone. Fine for dev, not for a production scheduler. For anything that must survive restarts, use Postgres Memory or Redis Memory.

Buffer memories eat tokens. The default buffer hands the whole thread back to the model on every run. A daily scheduled agent will, after six months, hand the model six months of history. Window Buffer Memory caps it at the last N messages; Summary Memory compresses the old stuff. Pick one before the bill teaches you.

Session collisions leak data across users. The flip side of a shared key: key per-user memory on something sloppy like a first name, and two customers named Sam share a memory thread. For multi-tenant agents the session key has to be genuinely unique per tenant. That one is a privacy bug, not just a quality bug.

The limit that session IDs cannot fix

Honest part: session IDs work inside one n8n instance. They do nothing for the agent that also runs in Make, or the one you chat with in Claude Code, or the heartbeat job in OpenClaw.

That was my actual problem. I had scheduled agents in n8n, a couple of Make scenarios, and Claude Code sessions, and each had its own perfectly functioning memory that knew nothing about the others. The n8n scheduler would "remember" inside n8n and still be blind to what I told Claude Code an hour earlier.

The fix is a memory layer that sits above the tools instead of inside them. I use Vilix AI for this. It is cloud-hosted, so there is nothing to run, and it connects over MCP, so the same memory follows the agent whether it wakes up in n8n, Make, OpenClaw, or a plain Claude Code session. It stores the full conversation history, not just extracted facts, and retrieval is semantic, so the agent finds what it meant rather than only what it typed. There is a free plan that never expires, and a 7-day Pro trial that does not ask for a credit card. If you ever want out, you can pull everything in a portable format or wipe the account instantly.

You do not have to use Vilix AI. But if your agents live in more than one tool, some kind of shared layer is not optional. Session keys solve memory inside n8n. They cannot solve memory across your stack.

A quick checklist

• Chat agent with real users: session key = stable user identifier. Postgres Memory for durability.
• Scheduled agent that should learn: session key = a fixed string per workflow. Window Buffer or Summary Memory to keep tokens under control.
• Stateless one-shot agent: execution ID as the key, or no memory node at all.
• Agents across multiple tools: a shared MCP memory layer so every run, in every tool, reads the same thread.

Start there and the "why does my agent forget everything" questions mostly answer themselves. Usually it was the session key all along.