Target query: share memory between n8n workflows
Slug: share-memory-between-n8n-workflows

Two n8n Workflows, One Brain: How to Share Memory Between n8n Workflows

Your morning triage workflow reads the inbox, flags the urgent items, and decides who gets a reply today. Your evening follow-up workflow checks which of those replies actually went out and escalates the ones that stalled. They are both AI agents. They both live in the same n8n instance. And they have never spoken to each other.

So you built the courier route: workflow A writes a summary to a sheet or a database row at the end of its run, and workflow B reads that row at the start of its run and stuffs it into its prompt. It works. It is also the moment your automation stops being a set of agents and becomes a fragile little data pipeline you now maintain by hand.

There is a better question than "how do I pass state between workflows." It is: why do two agents on the same team need a courier at all, when they could share one memory?

Why session IDs do not cross workflow boundaries

Inside a single workflow, n8n gives you a clean answer: the Window Buffer Memory node, keyed by a session ID. Same session ID across executions, and the agent remembers the conversation. That is session-scoped memory, and it is the right tool for one workflow talking to one user over time.

But the memory node is scoped to its own workflow by design. A session ID in workflow A means nothing to workflow B. Pointing two workflows at the same session ID string does not merge their memories, because each workflow's memory node reads its own isolated store. Community nodes built for queue-mode Redis memory deliberately hash the workflow ID into the key, so one workflow can never read another's history. That is not a bug; it is an isolation feature. It becomes a problem only when isolation is the default and you need the opposite.

The three ways operators actually do it today

1. The shared document. Workflow A appends a summary to a sheet, a Notion page, or a database row. Workflow B queries it and injects it into the prompt. Cheap and transparent, and it breaks the ways you would expect: schemas drift, two writes race, and the summary becomes a graveyard of stale statuses the agent cannot tell from current truth. You also pay the token tax every run, because the agent re-reads the whole document, including the parts it does not need.

2. A shared external store. Redis, Supabase, Postgres, or a vector database, wired into both workflows with explicit read and write steps. This handles scale and concurrency, but now you are a memory-infrastructure operator: you own the schema, the retention policy, the cleanup, the indexing, and the retrieval logic. Every new workflow gets its own read/write wiring.

3. A shared memory service over MCP. The memory lives outside n8n entirely, on a hosted service your workflows reach through the Model Context Protocol. Both workflows talk to the same memory account. No per-workflow session keys to align, no shared documents to parse, no Redis to babysit.

Options 1 and 2 are memory you built. Option 3 is memory you subscribe to.

What changes when the memory is shared, not copied

With a shared document, workflow B sees what workflow A decided to write down. It is a snapshot, and snapshots lie by omission: the reasoning behind the decision, the alternatives considered, the constraint discovered halfway through, none of it survives unless the summary format was designed to include it. Nobody does that.

With a shared memory, workflow B asks a question and gets an answer drawn from the full history. The morning workflow flags a lead as urgent and the memory holds the whole exchange. The evening workflow asks what stalled, and it gets the actual story: which email went out, what the reply said, which follow-up was promised and missed. That is the difference between handing someone a sticky note and handing them the case file.

It also fixes the versioning problem that shared documents create. When two workflows write to the same sheet, you get write conflicts and merge headaches. A memory layer with last-write-wins semantics just keeps the newest truth, and because retrieval is recency-aware, the newest version is what every agent sees. Correct something in one place and it is corrected everywhere.

How to set it up in practice

The mechanics are simpler than most people expect, because the memory lives outside the workflows:

1. Create one memory account. Every workflow you want to share context gets connected to the same one.
2. In each workflow, add an MCP client node pointed at the memory service, placed before your AI Agent node.
3. At the start of each run, the agent pulls relevant context. At the end of each run, it saves what it learned.

That is the whole integration. Adding a third workflow means connecting it to the same memory account, not rewiring the first two. One thing to know: connecting a client does not import its old history. The memory starts accumulating from the day you connect it, and the value compounds as the workflows keep reading each other's notes.

The boring parts you do not have to build

A cloud-hosted memory service handles all of that as the product: no infrastructure to manage, no containers to restart, no backups to schedule. Memory that lives outside your runtime cannot die with your runtime.

Where Vilix AI fits

Vilix AI is a cloud-hosted memory layer built for exactly this problem. Your n8n workflows connect to it over MCP as separate clients on one account, and they share the same memory: the morning workflow saves what it learned, the evening workflow reads it, no courier documents, no shared Redis to operate.

A few things that matter for automation operators specifically. It stores full conversation history, not just derived facts, so an agent can revisit what actually happened instead of trusting a summary. Retrieval is semantic, so an agent asking about "the stuck follow-ups" finds them even if the morning workflow described them as "pending replies." And the memory is shared across every connected tool, so the context your n8n workflow saves is also visible to the agent you run in Claude or Cursor.

It costs nothing to start: the free plan is free forever, and there is a 7-day Pro trial with no credit card. Your data stays portable, export everything or delete it anytime, in a portable format. You are not locked into the memory layer any more than you are locked into any other API.

The real test

Pick your two workflows that most need each other's context. Run them against one shared memory for two weeks and watch what stops happening: the morning summary you used to write for the evening agent, the duplicate escalations where both workflows flagged the same lead. None of that was a prompt problem. It was always a memory problem.

Two workflows, one brain. The courier can retire.