n8n AI Agent Memory Between Executions: How to Keep Context

Every n8n execution starts with a blank slate. When one run ends, everything the AI agent learned during that run is gone, so the next execution begins as if the previous one never happened. To keep memory between executions, save the agent's context to an external store at the end of each workflow run and load it back at the start of the next one, keyed by workflow ID plus chat or session ID. n8n's built-in memory options only cover conversations on the same instance and do not survive as durable cross-execution memory.

Why do n8n executions start stateless?

n8n treats each execution as an isolated run. Nodes receive input data, do their work, and pass results downstream; nothing carries over to the next execution unless you deliberately persist it somewhere. This design keeps workflows predictable and debuggable, but it is hostile to agents that need continuity.

For an AI Agent node, this means the chat history, the decisions the agent made, and any facts it extracted from tool calls all evaporate when the execution finishes. A customer support bot greets a returning user like a stranger. A research agent re-fetches the same sources every morning. A lead-scoring agent re-derives conclusions it already reached yesterday. The cost is not just embarrassment: it is duplicated tool calls, wasted tokens, and agents that never compound knowledge over time.

What built-in memory options does n8n offer, and where do they fall short?

The n8n AI Agent node ships with several memory options under its Memory sub-node:

• Window Buffer Memory keeps the last N messages of the current conversation, keyed by a session ID you provide.
• Simple Memory does the same in a lighter form, also session-keyed.
• Redis Chat Memory, MongoDB Chat Memory, Postgres Chat Memory, and Zep persist chat history to an external database so it survives across executions.

These cover the common chat case: one user, one ongoing conversation, one n8n instance. But they have hard limits. The built-in options store raw message history, not distilled knowledge; there is no semantic recall, only replay of the last N messages. The memory is scoped to the session key you manage by hand, and it does not travel between workflows or between n8n instances. If you run a scheduled agent rather than a chat agent, there is no session at all, and you are back to wiring persistence yourself.

What is the external-store pattern for n8n agent memory?

The reliable pattern is simple and works for chat agents, scheduled agents, and multi-step workflows alike:

1. At the start of the workflow, load the agent's saved context from an external store.
2. Run the agent with that context injected into its prompt or memory.
3. At the end of the workflow, save the new context (decisions, extracted facts, updated state) back to the store under the same key.

This turns memory into an explicit data flow you control, instead of something hidden inside the AI Agent node's session handling. It works across executions, across workflows, and across n8n instances, because the store lives outside n8n.

How do you key memory so sessions don't leak into each other?

The key is the part most people get wrong. Use a composite key: workflow ID + conversation or session identifier. For a Telegram bot, that is the chat ID. For a webhook-triggered agent, it is a session ID you generate and pass back to the caller. For a scheduled agent with no user, key by workflow ID plus the entity it operates on (for example, the customer ID, the repository name, or the campaign ID).

Never use a single global key for everything. One shared key means every conversation bleeds into every other, and the agent starts answering user B with user A's context. And never rely on n8n's default session key alone if the same workflow serves multiple users; the default is a static string unless you override it.

How do you save and load memory in an n8n workflow?

Here is the concrete setup, step by step:

1. Add a "load" step at the top of the workflow. Use an HTTP Request node (or your store's dedicated node) to GET the stored context for the current key. If the key does not exist yet, treat the result as empty and continue.
2. Inject the loaded context into the agent. Pass it into the AI Agent node's system message or a memory input, so the agent starts the run aware of prior state.
3. Run the agent as normal. Let it call tools, make decisions, and produce its output.
4. Extract what is worth keeping. Do not save the entire raw transcript forever; have the agent (or a small follow-up LLM call) distill decisions, facts, and open tasks into a compact JSON object.
5. Save at the end of the workflow. Use an HTTP Request node to POST or PUT the distilled state back to the store under the same composite key, overwriting the previous version.
6. Set a retention policy. Decide how long each key lives. Chat sessions can expire after days of inactivity; entity state (like a customer profile) can live indefinitely.

Which external store should you use?

Any durable store works: Redis, Postgres, or MongoDB via n8n's chat memory nodes if you only need message history. If you want the same memory available to agents running outside n8n too, Vilix AI is one option: it is a cloud-hosted memory layer your n8n workflow reaches over HTTP and your other AI tools reach over MCP, so context saved by a scheduled n8n agent can be recalled later in Claude or Codex. The honest tradeoff is that it is cloud-only; if your policy requires everything self-hosted on your own infrastructure, a database you run yourself is the better fit.

The takeaway

n8n will not remember anything for you between executions unless you build the loop yourself: load at the start, run, save at the end, keyed by workflow plus session. Once that loop is in place, your agents stop re-learning the same lessons every run and start compounding knowledge like a system that actually keeps a journal.