Does Flowise Remember Between Sessions?

Yes, inside one session, but not automatically across sessions. Flowise keeps the conversation going while a session lasts: its Buffer Memory node stores chat messages so the model can use earlier turns in the same conversation. Start a new session, though, and the agent starts from a blank conversation unless you have wired up memory that survives the session boundary.

That distinction is the whole question for anyone shipping a Flowise agent. A chatbot that remembers what a customer said five messages ago is doing its job. An agent that asks the same customer the same questions next week, because the new session has no link to the old one, is not.

What Flowise memory actually does

Flowise is a visual builder for LLM applications. You drag nodes onto a canvas: a chat model, a chain or agent, and a memory node. The memory node is what gives the conversation its short-term continuity.

The standard setup works like this:

1. Add a chat model node, such as a ChatOpenAI node, to the canvas.
2. Add a conversation chain or conversational agent and connect the model to it.
3. Add a Buffer Memory node from the Memory section and connect it to the chain or agent.
4. The Buffer Memory node stores the chat messages, so each reply can take earlier turns in the same session into account.

That is session memory, not user memory. It answers "what did we just talk about" rather than "who is this person and what have we already settled with them."

Why a new session starts blank

Flowise sessions are keyed by a session identifier. Reuse the same session identifier and the agent can pick up the thread, because the stored messages for that session are still there to draw on. Open a fresh session and there is no stored thread to draw on, so the agent has nothing from the earlier conversation.

This is easy to miss during testing. If you test in the same chat window, everything looks remembered. The gap only shows up when a real user returns later, through a different channel or a new chat, and the agent treats them like a stranger.

What are the memory options inside Flowise?

Flowise offers more than the basic buffer. Its memory nodes connect to external storage, so the conversation history for a session can live in a real database instead of only in the running flow. The options include Redis-backed chat memory, DynamoDB chat memory, Zep memory with summarization, and Motorhead memory. Each one changes where the history is stored and how long it lasts, but the scope stays the same: history tied to a session.

That leaves two practical gaps for a shipped agent. First, history is organized by session, not by person, so the same customer in two sessions looks like two different people. Second, the stored history is the raw conversation, not the distilled facts that matter next time: the decision that was made, the preference that was stated, the issue that is still open.

How do you get memory that survives a session?

There are three realistic paths, and the right one depends on how much infrastructure you want to run.

First, keep using session memory and design around it. Give returning users a stable session identifier where your product allows it, and keep each session focused on one task. This works when the conversation itself is the product, and it costs nothing extra.

Second, add a persistent memory store behind the agent. This is the path third-party Flowise tool nodes take: they give the agent explicit retain and recall steps, so it can save facts from one session and pull them back in a later one. You choose the storage, you run or subscribe to it, and you decide what gets saved.

Third, plug in a hosted memory layer that sits outside Flowise entirely. This is where a hosted memory layer fits. A built agent connects to Vilix AI with an API key as a Bearer header to https://api.vilix.ai/mcp and gets full memory with zero memory infrastructure to run. The memory lives outside any single session, so the agent can pull relevant context from earlier sessions and other tools before it answers, and save what it learned for next time.

The third path changes what the agent can answer. Instead of "what did this session say," the question becomes "what do we already know about this person and this work," no matter which session or tool the new message arrives in.

How should you choose?

Ask what your agent needs to remember, not just what it needs to chat about.

• If every conversation is standalone and nothing from one chat should carry into the next, Flowise's built-in session memory is enough.
• If the same people return and expect the agent to know them, you need memory keyed to the person, not the session.
• If your agents run in Flowise and also in other tools, you need memory that follows the work across tools instead of staying trapped inside one chatflow.
• If you do not want to run and maintain another database, a hosted layer removes that work.

Frequently asked questions

Does Flowise remember a conversation after the chat window closes?

Only if the session is reopened with the same session identifier and its stored history is still available. A new session does not automatically inherit an old conversation.

Is Buffer Memory enough for a production support agent?

It is enough for continuity inside one conversation. It is not a customer memory: it does not connect a returning customer to their earlier sessions, decisions, or open issues on its own.

What is the difference between session memory and user memory?

Session memory is the transcript of one conversation. User memory is what the agent knows about a person across conversations: preferences, decisions, history, and open items. Production agents usually need the second one.

Do I need to run my own database for Flowise memory?

Not necessarily. Session memory can use Flowise's built-in options, and a hosted memory layer means no database to run at all. Running your own store only makes sense if you specifically want to operate that infrastructure yourself.

The short answer

Flowise remembers between turns, and it can keep a session's history available while that session lasts. It does not, by default, remember a person between sessions. If your agent needs to recognize returning users and carry what was learned forward, add a memory layer that is scoped to the person and the work, not just to the session.

Learn more about shared agent memory at https://vilix.ai/?utm_source=vilix-blog&utm_medium=article&utm_campaign=icp1-visibility