Your Flowise Agent Remembers the Chat. Your Scheduled Runs Start Blank.

You set up a Flowise flow that runs every night at 11 PM. It reads the shared inbox, drafts replies to the routine messages, and flags the ones that need a human. The first few nights are smooth. Then the drafts start degrading. It drafts a reply to a thread it already resolved last Thursday. It asks who "the Austin account" is, a question it got answered twice the week before. It re-flags the same newsletter as suspicious three nights in a row.

The confusing part is that memory clearly works. Open the flow in the canvas, chat with it, and it remembers what you said five minutes ago. So the memory component is fine. The problem is not whether Flowise remembers. It is what a scheduled run is: a brand-new session, every single time.

What Flowise memory actually is

Flowise does not have a global memory that floats above your flows. It has memory components, and every one of them keys conversation history to a session ID. While a session is alive, the agent sees the earlier turns in that session, so it can reference prior messages, build on earlier tool results, and stay consistent with decisions it already made. End the session and start a new one, and the history behind it is unreachable.

In the canvas chat, this feels like memory, because your conversation is one long session. The flow keeps answering in context and you conclude the agent remembers things. It does, within that session. But a cron job calling your flow's API endpoint is not continuing that conversation. Each scheduled execution is its own session, and unless the call passes a session ID that ties it to an earlier one, the memory component has exactly one run of history to work with: the run that is happening right now.

This is the entire architecture in one sentence. Everything else is consequences.

The consequence operators discover in production

The nastiest consequence is the split between testing and production. You build and test in the Flowise UI, where the session persists across your test messages. Memory behaves. Then you point your scheduler at the API, and the same flow starts acting clueless. The configured session ID on the memory module, which worked in the UI, does not carry over to the API or embed path, where calls land in random sessions instead. This is not speculation; it is a long-standing community report that matches what operators keep rediscovering.

So you get the worst debugging experience in automation: the flow works on your screen and fails in production, with no error, no warning, and no visible difference in the logs. The memory writes succeed. They are just written to sessions nobody ever reads again. Your nightly run diligently records what it did and then starts tomorrow night having forgotten everything, because forgetting is the default and remembering has to be requested.

Three ways to fix it, with honest tradeoffs

One: pass a stable session ID from your scheduler. Include the same sessionId with every API call, and the session memory becomes shared across runs. This is the native answer and it costs nothing new. The costs arrive later. Sessions accumulate without bound, so the model re-reads old context as current and you pay for it in tokens every turn. You will need a retention strategy, pruning old turns or summarizing them, or the shared session turns into a bloated, stale mess. And if one flow serves multiple inboxes, queues, or users, a single session ID means context bleed: the agent starts mixing up threads that belong to different tenants. You fix that with one session ID per tenant, and now you are managing a session registry.

Two: keep the memory yourself in an external store. End each run by writing a compact summary, decisions, open items, resolved mappings, to Postgres, a vector database, or even a file, and start each run by reading it back. This is the most flexible option. It works across flows, survives redeploys, and you control exactly what is kept. It is also a second system to build and maintain: schema, retention, retrieval quality, isolation, and the weekly debugging when the retrieval step returns the wrong summary on the morning that mattered.

Three: put a memory layer underneath the agent. Instead of keying memory to sessions, give the agent a shared store it writes to at the end of a run and reads from at the start of the next one, reachable from any tool. Vilix AI is built for exactly this shape of problem. It is cloud-hosted with zero infrastructure, so there is no database to operate and no session registry to maintain. The same memory is available to every MCP-compatible client, which means the Flowise flow, the n8n workflow, and the cron script can all read and write one shared memory instead of each keeping a silo. It stores full conversation history, not just extracted facts, so "why did we decide this" stays inspectable. There is a free plan that is free forever, a 7-day Pro trial with no credit card, and your data is portable: export everything or delete it anytime in a portable format.

The audit to run this week

If any of this sounds familiar, run the audit. List every Flowise flow that triggers on a schedule or through the API. For each one, find the session ID the trigger actually sends. If the answer is "none" or "whatever the default is," that flow has no cross-run memory, regardless of which memory component is on the canvas. Then decide the policy on purpose: which runs share a session, how sessions get pruned, and where the durable record of decisions lives.

Most teams discover the same thing this audit reveals. The chat memory was never meant to be the operational memory. It records a conversation. Your scheduled runs need a record of conclusions, and that is a different system, whether you build it or borrow one.

The bottom line

Your Flowise agent remembers the chat because the chat is one session. Your scheduled runs start blank because each one is a new session and nobody told the API otherwise. Flowise gives you the mechanism, a stable session ID, and leaves the policy to you. Set the policy deliberately, or move the memory to a layer where remembering is the default instead of something each caller has to remember to request.