Full Pro free for 7 days, no credit card. Start free →
← All posts
September 24, 2026 · 4 min read

Your Morning Workflow Already Knows This. Teach the Evening One.

Target query: share memory between n8n workflows (companion rewrite) Slug: your-morning-workflow-already-knows-this Published: 2026-09-24 Surface: vilix.ai blog (full rewrite of share-memory-between-n8n-workflows) Your Morning Workflow Already Knows This. Teach the Evening One. The same lead got escalated twice this week. The morning triage workflow flagged it as urgent at 8 AM. The evening follow-up workflow, running at 6 PM, flagged it as urgent again, because the follow-up had been promise

Target query: share memory between n8n workflows (companion rewrite) Slug: your-morning-workflow-already-knows-this Published: 2026-09-24 Surface: vilix.ai blog (full rewrite of share-memory-between-n8n-workflows)

Your Morning Workflow Already Knows This. Teach the Evening One.

The same lead got escalated twice this week. The morning triage workflow flagged it as urgent at 8 AM. The evening follow-up workflow, running at 6 PM, flagged it as urgent again, because the follow-up had been promised, sent, and replied to, and the evening workflow knew none of that. Two agents. Same n8n instance. Total strangers.

This is the quietest failure mode in scheduled automation. Nothing errors. Nothing crashes. Every workflow runs green. They just do not know each other, so they keep rediscovering the same facts and re-doing the same decisions. You pay for every rediscovery twice: once in tokens, once in the mistakes that a five-minute glance at the morning's work would have prevented.

The workaround everyone builds first

Most operators solve it with a courier. The morning workflow appends a summary to a Google Sheet, a Notion page, or a Postgres row. The evening workflow reads it and injects it into its prompt. It is honest work, and it gets you most of the way there. But look at what you have built: a hand-rolled state pipeline between your agents, with all the maintenance that implies.

Snapshots rot. Somebody has to decide the summary format. The format never includes the reasoning, only the conclusion, so the evening agent inherits the verdict without the evidence. Two workflows writing at the same time race each other. And the old entries never really leave, so every run re-reads months of stale status at full token price, hoping the agent can tell April's truth from today's.

Session IDs do not rescue you here. n8n's memory nodes are scoped to a single workflow: the same session ID string in two different workflows points at two different stores. That is deliberate isolation, and it is the right default for chat. It is just the wrong default for a team of agents that are supposed to work together.

What one brain changes

When two workflows share a real memory instead of exchanging summaries, the evening workflow does not read the morning's notes. It asks what happened and gets an answer drawn from the full history: which email went out, what the reply said, which follow-up was promised and missed. The morning's reasoning survives, not just its conclusion. The evening agent can check the evidence instead of trusting a verdict.

This also ends the versioning war. Shared documents have merge conflicts; a shared memory has one newest truth. Last write wins, retrieval is recency-aware, and the newest version is what every agent sees. Fix a lead's status in one place and it is fixed everywhere. Nobody maintains the summary format anymore, because there is no summary format. The agents just remember.

The shape that scales

Keep the memory outside n8n, on a service your workflows reach over MCP. Both workflows connect to the same memory account, so adding a third workflow later means connecting it to the same account, not rewiring the first two. No session keys to align across workflows, no shared Redis to operate, no state pipeline to babysit.

Getting started takes less time than building the courier. Create one memory account. In each workflow, add an MCP client node pointed at the memory service, placed before the AI agent node. At the start of a run the agent pulls relevant context; at the end it saves what it learned. One caveat worth knowing: connecting a client does not import its old history, so the memory starts accumulating from day one. The first week each workflow mostly saves its own notes; by the second week they are reading each other's, and the value compounds from there.

The boring parts are where this pays off most. Retention, cleanup, access control, export, uptime: with a self-built store, you own all of them. With a hosted memory service, they are the product. Scheduled agents have a failure mode every operator knows: everything works in development, then a container restart in production wipes the agent's brain at 3 AM with no error and no warning. Memory that lives outside your runtime cannot die with your runtime.

Where Vilix AI fits

Vilix AI is a cloud-hosted memory layer for exactly this setup. Your n8n workflows connect as separate clients on one Vilix AI account over MCP, and they share one memory: the morning workflow saves what it learned, the evening workflow reads it, no courier documents, no infrastructure to manage. It stores full conversation history, not just derived facts, so agents revisit what actually happened. Retrieval is semantic, so "the stuck follow-ups" are found even when the morning workflow called them "pending replies." And the same memory follows you into Claude, Cursor, or Codex, so the context your automations build is visible everywhere you work.

The free plan is free forever, with a 7-day Pro trial that needs no credit card. Your data stays portable: export everything or delete it anytime, in a portable format.

Two workflows, one brain. Stop paying the courier.

Try Vilix Pro free for 7 days

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Start 7-day free trial
Keep reading
Yesterday's Report Is Not a Memory: A Better Way to Give Scheduled Agents a Past

Yesterday's Report Is Not a Memory: A Better Way to Give Scheduled Agents a Past A scheduled AI agent runs every morning, and every morning it starts as a stranger to itself. The standard fix in automation circles is to have each run write down what it did, somewhere the next run can read: a row in a spreadsheet, a record in a database, a value in n8n's static data. Tomorrow's run reads yesterday's note and continues. It works well enough that most people stop there. It is worth being precise

The "Already Handled" List: How to Stop Your AI Agent From Re-Processing the Same Items Every Run

Target query: how to stop scheduled ai agent redoing the same work Slug: agent-completion-ledger-stop-redoing-work Published: 2026-09-23 Surface: vilix.ai blog (Ghost) (this version) Companion piece (dev.to, full rewrite): scheduled-agent-memory-of-done-completion-ledger.md * dev.to: TBD * vilix.ai blog: TBD The "Already Handled" List: How to Stop Your AI Agent From Re-Processing the Same Items Every Run A prospect gets the same follow-up email twice in three days, because Wednesday's run

Your AI Agent Remembers Everything and Still Gets It Wrong

Target query: why does my ai agent forget even with memory enabled Slug: ai-agent-memory-vs-state-scheduled-automations Your AI Agent Remembers Everything and Still Gets It Wrong Picture this. You did everything right. Your scheduled agent stores full conversation history between runs. Every morning the workflow loads yesterday's runs, the corrections, the context. The memory system works. And yet, Tuesday morning your support agent tells a customer their refund is still pending, when the fin