n8n wipes your AI agent's memory every execution. Here's the workaround.

You build a support bot in n8n. It works great in testing. Then it goes live, and a customer who talked to it yesterday gets asked "how can I help you today?" like they've never met. The bot resolved their billing issue in the last chat. It just doesn't remember.

This isn't a bug you introduced. It's how n8n works: every execution is stateless. When a run ends, the AI Agent node drops everything. The fix is a load-at-start, save-at-end loop with an external store. Here's exactly how to build it.

What n8n remembers out of the box (and what it doesn't)

The AI Agent node has memory sub-nodes: Window Buffer Memory (last N messages), Simple Memory, plus Redis, MongoDB, Postgres, and Zep chat memory that persist to a database.

Good enough if you have one chat user on one n8n instance. Not good enough when:

• the agent runs on a schedule with no chat session at all,
• you need distilled knowledge, not a raw replay of the last 20 messages,
• memory has to survive across workflows or across n8n instances,
• you want semantic recall instead of dumb message history.

Scheduled agents are the big gap. A nightly triage agent has no session key, no conversation, and no built-in memory that fits. You have to wire persistence yourself.

The pattern: treat memory as a data flow

Stop thinking of memory as something the agent node handles. Make it two HTTP calls in your workflow:

Load step (first node after the trigger). Fetch stored state for this run's key. Key doesn't exist yet? Fine, continue with empty state.

Save step (last node). Write back what changed: new decisions, new facts, updated task list. Overwrite the previous version under the same key.

Everything between those two calls is your normal agent logic, except the agent now starts each run already briefed.

Keying: the part everyone screws up

Composite key, always: workflow-id + who-or-what-this-run-is-about.

• Telegram/WhatsApp bot: chat ID from the incoming message.
• Webhook agent: a session ID you generate and return to the caller on first contact.
• Scheduled agent with no user: workflow ID + the entity, e.g. triage-agent:acme-corp or digest:repo-frontend.

One global key = every user's context leaking into every other user's conversation. The agent will cheerfully answer user B using user A's billing details. Don't do that.

Building it in n8n, step by step

Say you're running a nightly lead-research agent. Every night it researches new signups and scores them. Without memory, it re-researches the same companies when they sign up for a second product.

1. Trigger fires on schedule.
2. HTTP Request (GET) loads research-agent:leads from your store (Redis, Postgres, whatever you run).
3. Set node merges loaded state into the input the agent will see.
4. AI Agent node runs with a system prompt like: "You have prior research below. Only research what is new or changed."
5. A small LLM call distills the run's output into compact JSON: companies researched, scores, open follow-ups. Raw transcripts rot; distilled state compounds.
6. HTTP Request (PUT) saves the distilled JSON back under the same key.
7. Retention: give chat-session keys a TTL (say 14 days of inactivity). Keep entity keys like customer profiles indefinitely.

That's it. Six nodes around your existing agent, and it stops having amnesia.

What to store in (and what to leave out)

Store decisions, extracted facts, and open loops. A customer profile, a lead score with its reasoning, the list of sources already checked. Skip full transcripts; they bloat the store and burn tokens on every load. A hundred lines of distilled JSON beats ten thousand lines of chat log every time.

One more thing: store state your agent can act on, not just read. "Customer asked for a refund twice, escalate next time" is useful. "User said hi" is not.

Store options

If raw message history is all you need, n8n's Redis or Postgres chat memory nodes are the shortest path. If you want the same memory reachable from agents outside n8n, Vilix AI is worth a look: your workflow hits it over HTTP, and the same context is available to your other AI tools over MCP, so a scheduled n8n run and a Claude session can genuinely share state. Tradeoff, stated plainly: it's cloud-hosted, so if your setup has to be fully self-hosted, run your own database instead.

Bottom line

n8n executions are stateless by design, and no built-in memory option fixes that for scheduled or multi-workflow agents. The workaround is unglamorous and it works: load state at the start, save state at the end, key it properly. Build that loop once and every agent you run in n8n gets a memory that actually survives the night.