---
title: "Flowise memory: chat memory nodes and dated recall"
description: "Flowise memory nodes store chat history per session ID, and Agentflow V2 nodes read the current thread. Add timestamped recall with a Custom Tool or Custom MCP."
canonical: https://past.dev/integrations/flowise
last-updated: 2026-10-09
---
# Add memory to Flowise agents

Source: https://past.dev/integrations/flowise

Flowise memory is conversation memory. The memory nodes store chat history in arrays or databases, keyed by a session ID, and give it to the model as context. In Agentflow V2, the Agent and LLM nodes read the history of the current conversation thread. A Custom Tool that calls past.dev over HTTP adds timestamped ingestion and recall that returns ranked documents with dates and source excerpts.

## Flowise memory scope

[Memory nodes](https://docs.flowiseai.com/integrations/langchain/memory) store conversations in arrays or databases and give them to the model as context. They include Buffer Memory, Buffer Window Memory, the conversation summary memories, and chat memory backed by DynamoDB, MongoDB Atlas or Redis. Each node takes a **Session ID**, which separates the conversations of different users.

In [Agentflow V2](https://docs.flowiseai.com/using-flowise/agentflowv2), the Agent and LLM nodes have a Memory setting that includes the history of the current conversation thread, with a memory type, a window size or a token limit. The Start node can set Ephemeral Memory to begin a run with no past messages, and Flow State carries key-value data through one run.

- **Memory is a transcript.** The nodes keep messages, or summaries of messages, for a session.
- **Scope is the session ID.** A new session starts with no history unless the application reuses the ID.
- **No fact model is documented.** The documentation describes no event time and no validity period for a fact.

## The integration: a Custom Tool per endpoint

A [Custom Tool](https://docs.flowiseai.com/integrations/langchain/tools/custom-tool) has a name, a description, an input schema and a JavaScript function. The function reads each input as `$<property>`, reads [variables](https://docs.flowiseai.com/using-flowise/variables) as `$vars.<name>`, and can call `fetch` from `node-fetch`.

Create two variables: `pastApiKey` for the project key, and `pastIdentity` for the user. Enable variable override, and your application sets `pastIdentity` for each request through `overrideConfig.vars`. A flow is public by default, so assign it an API key and call its prediction API from your server ([flows](https://docs.flowiseai.com/configuration/authorization/chatflow-level)). Only your application then sets `pastIdentity`. The tools read it from `$vars`, and their input schemas do not carry it.

```javascript
// Tool name: recall_memory. Input schema: question (string, required).
const fetch = require('node-fetch');

const response = await fetch('https://api.past.dev/api/v1/recall', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${$vars.pastApiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ query: $question, identity: $vars.pastIdentity }),
});
return await response.text();
```

```javascript
// Tool name: remember. Input schema: text (string), happened_at (string, ISO 8601).
const fetch = require('node-fetch');

const response = await fetch('https://api.past.dev/api/v1/ingest', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${$vars.pastApiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ content: $text, timestamp: $happened_at, identity: $vars.pastIdentity }),
});
return await response.text();
```

Attach both tools to an Agent node. For a recall step that runs on every turn, the Agentflow V2 HTTP node can send the same request with a Bearer Token credential.

> **Identity**
>
> The application sets the identity. The model never chooses it. Recall returns what the identity in the request may read, so take the identity from the signed-in user in code, and keep it out of every value that the model fills.

Recall returns ranked documents with dates and source excerpts. The application decides whether those documents support an answer, contain a disagreement, or are insufficient; HTTP failures are handled separately.

## Or connect the MCP server

Flowise connects an Agent node to a remote MCP server through a **Custom MCP** tool over Streamable HTTP. Its configuration is JSON with a `url` and optional `headers`, and it accepts variables as `{{$vars.<name>}}` ([Tools and MCP](https://docs.flowiseai.com/tutorials/tools-and-mcp)). The project's end-user MCP server then gives the agent `recall`, `answer` and `who_am_i`, plus `remember` while the project's write toggle is on, with no tool code to write.

1. Turn on the project's end-user MCP server on **Build › MCP server** in the console.
2. Mint an access link there, or with the account server's `create_mcp_access_link` tool. The link has the form `https://api.past.dev/mcp/<handle>/link/<secret>`. It is one URL that is one identity, and the server answers it with no sign-in step.
3. Keep the link in a Flowise variable, such as `pastMcpUrl`, which the configuration below reads. The secret in its path is the credential.

```json
{
  "url": "{{$vars.pastMcpUrl}}"
}
```

Refresh **Available Actions** to load the tools into the Agent node.

Every call through the link runs as its identity, with that identity's audiences. Mint one link per install, so that a revoked link stops one agent only. When the agent serves several people, mint one link per end user, and connect each request with the link of the user who makes it. Never share one link between users. `remember` writes to the identity's own private audience, and only that identity recalls it. Send data that the whole project must recall through the ingest call. The [end-user server documentation](/docs/mcp/serving-your-own-users) describes the tools, the links and revocation.

## When to use which

- Follow-up questions inside one session: a memory node, or the Memory setting of an Agentflow V2 node.
- Data that one run passes between nodes: Flow State.
- Facts that must reach other sessions, flows and applications, with dates and source excerpts: the Custom Tools or the MCP server above.

The [quickstart](/docs/memory-api/quickstart) shows how to ingest, wait until ingestion completes, and recall. The [benchmarks](/benchmarks) document how recall is measured. [Session memory](/glossary/session-memory) defines the layer the memory nodes provide.

## Frequently asked questions

### Does Flowise have long-term memory?

Flowise memory nodes keep chat history per session ID, in memory or in a database. Facts that must outlive a session, or reach other flows and applications, need a store that the flow calls.

### Can several Flowise flows share one memory?

Yes, through the API. Every flow whose tools hold a key for the same project recalls the same data, scoped by the identity that each call names.

## Related

- [Memory for n8n](https://past.dev/integrations/n8n)
- [Memory for Dify](https://past.dev/integrations/dify)
- [Memory for LangChain](https://past.dev/integrations/langchain)
- [Session memory](https://past.dev/glossary/session-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)