How to Add Shared Memory to n8n AI Agent Workflows

The short answer: n8n's built-in memory options are scoped to a single workflow and a single session key, so agents in different workflows can never see each other's context. To add shared memory, you keep a store outside n8n that every workflow reads from at the start of a run and writes back to at the end. The pattern that actually holds up in production is two layers: per-workflow chat memory for the current conversation, plus one shared store for the durable facts, decisions, and handoffs every workflow needs.

Why does every n8n workflow end up with its own memory island?

Because the built-in Memory sub-nodes were designed for one job: keeping a conversation going inside one workflow. Window Buffer, Postgres Chat Memory, Redis Chat Memory, the Zep node — they all store messages keyed by a session ID that you manage inside that workflow. The docs walk you through wiring one up, so most people wire up four of them across four workflows and call it done.

Then the research workflow finds something at 7am, the qualifier workflow re-discovers the same thing at 9am and flags it as new, and nobody can figure out why two "smart" agents keep redoing each other's homework. The answer is structural: each workflow wakes up in its own little world. A chat memory node remembers the conversation it saw. It has no view into any other workflow's conversation, and it was never meant to.

What does shared memory actually mean here?

Shared memory is a single store, outside n8n, that multiple workflows and multiple agent steps read from and write to. The useful mental model from operators who run this setup:

• n8n handles orchestration — triggers, branching, retries, scheduling, the boring deterministic plumbing it is great at.
• AI agents act as steps — one step does fuzzy work (triage, draft, decide), then hands off.
• The shared store holds the running state — facts found, decisions made, constraints set, what already completed, so the next step, run, or workflow continues with context intact.

One operator on r/n8n described the target architecture plainly: a flow that researches something, stores the findings, continues later with context intact, and sends results anywhere. That only works when the memory lives outside the workflows.

What is the two-layer memory pattern?

Trying to make one store do everything is how you get a swamp. The setup that survives contact with real operations splits memory into two layers:

1. Layer one: per-workflow chat memory. Keep the built-in memory nodes for what they are good at — the current conversation. The triage assistant's back-and-forth with a user, the follow-up drafter's session history. Scoped, short-lived, session-keyed. Do not fight this layer; it is fine.
2. Layer two: the shared store. This holds only durable, distilled knowledge: what was decided, what was tried and ruled out, constraints the next agent must respect, open items across workflows. Raw chat transcripts do not go here. Summaries written by the agent at the end of a run go here.

The two layers fail independently and that is the point. If the shared store has a bad day, the chat agent still converses. If a chat session expires, the durable knowledge survives.

How do you wire a shared store into n8n?

Step by step, for each workflow that participates:

1. Pick the store. Postgres, Redis, MongoDB, Supabase — anything durable with a key-value or document shape. If agents outside n8n should share the same memory (Claude Code, Codex, a phone app), the store needs an HTTP API the workflow can reach; that requirement rules out stores only reachable from inside one n8n instance.
2. Design the keys. Use a composite key that matches the grain of the knowledge: client:<id>, campaign:<id>, or topic:<slug>, not one global key and not a per-session key. Per-session keys recreate the memory islands. One global key lets every run bleed into every other.
3. Add a load step at the top of the workflow. An HTTP Request or database node fetches the stored state for the run's key before the agent step executes. Missing key means first run; continue with an empty state.
4. Inject the loaded state into the agent step. Put it in the system message or the agent's context input, labeled clearly ("Known facts from previous runs:", "Open items:"). The agent cannot use memory it cannot see.
5. Add a write-back step at the end. After the agent finishes, a follow-up step distills what is worth keeping — decisions, facts, constraints, what completed — and writes it back under the same key, replacing the previous state. This is the step people skip, and it is the one that matters.
6. Give every agent-as-step the same write contract. If four workflows share a store but each writes a different shape, reads become archaeology. One schema: facts, decisions, constraints, open_items, last_updated. Enforce it in the write-back step, not in prompts.

What should you write to the shared store, and what should you leave out?

This is where shared memory succeeds or rots, and it is a policy question, not a storage question. A strict write policy, agreed once and enforced in code:

• Write: decisions and why they were made, facts extracted from tool calls, constraints future steps must respect (budgets, preferences, what was ruled out), completed vs. remaining work.
• Never write: raw transcripts, speculative agent guesses stated as fact, anything that has not been verified or is marked as a guess. A guess that survives three handoffs turns into a "fact" nobody ever checked.
• Expire: per-run scratch state once the run completes; keep entity-level knowledge (per client, per campaign) indefinitely, with a last_updated field so readers can judge staleness.

The store does not rot because of the database. It rots because writes had no policy. The strictness of the write step is the whole game.

What goes wrong most often?

Three failure modes account for most of the pain:

• The islands re-form. Someone adds a fifth workflow and wires only the chat memory node, forgetting the load/write-back steps. Audit: every workflow with an agent step should have both.
• Stale facts poison new runs. Nothing ever expires or gets corrected, so the agent keeps acting on last month's truth. Fix: the write-back step overwrites, never appends blindly, and last_updated is mandatory.
• Conflicting writes. Two scheduled runs touch the same key at once. Keep the state small and the writes idempotent — last write wins on the whole document is usually fine for operational state, and scheduled workflows should avoid overlapping executions on the same key.

Which store should you use?

If everything lives inside n8n and self-hosting is a requirement, a Postgres or Redis you run yourself is the honest answer — you already operate the infrastructure, and the chat memory nodes plug straight in.

If your agents also live outside n8n — Claude Code, Codex, Cursor, a mobile app — a shared layer over HTTP is worth a look. Vilix AI is one option: the n8n workflow reaches it over HTTP while your other tools connect over MCP, so the context a scheduled n8n agent saved can be recalled later in a completely different tool. The honest tradeoff is that it is cloud-only; if your policy requires everything on your own infrastructure, a database you operate yourself is the better fit.

The takeaway

n8n gives you orchestration and per-workflow conversation memory. Shared memory across workflows is a second system you build deliberately: a store outside n8n, composite keys, a load step at the start, a strict write-back step at the end, and the same write contract on every participating workflow. Once that loop exists, your workflows stop waking up as strangers and start building on each other's work.

Frequently asked questions

Can two n8n workflows share one memory node?

Not directly. Memory nodes are scoped to the workflow and the session key you configure inside it. Sharing across workflows requires an external store both workflows read from and write to.

How is this different from n8n's Postgres Chat Memory?

Postgres Chat Memory persists chat messages for one session key inside one workflow. A shared store holds distilled, cross-workflow state — facts, decisions, constraints — keyed by entity (client, campaign, topic), not by chat session.

Do agents-as-steps need the full shared state every run?

No. Load the state, then let the workflow pass only the relevant slice into each agent step's prompt. Loading everything into every prompt wastes tokens and dilutes attention; the store is the archive, the prompt is the briefing.

Does Vilix AI work as a shared store for n8n?

Yes. The workflow reaches it over HTTP, other tools connect over MCP, and the same memory follows the user across tools. It is cloud-hosted, so self-host-only policies should use their own database instead.