🇬🇧 EN

🧠 Memory

A configuration node that connects a Memory Provider to an Agent node in graph mode. It enables the agent to read prior conversation turns from persistent storage and write new turns after each response, giving the agent a continuous memory across multiple workflow runs.

Category: AI & Agents · Type identifier: memory · Graph mode only

Overview

By default, each Agent node run is stateless — it has no knowledge of what the agent said or did in previous runs. The Memory node changes that. When connected to an Agent via the memory_in port, Flusso will automatically:

Read prior turns before the agent runs. Flusso queries the configured Memory Provider for the most recent conversation turns (up to the configured limit) and injects them into the agent's context as conversation history.
Write a new turn after the agent responds. Once the agent produces its response, Flusso writes both the user message and the agent's reply back to the Memory Provider as a new turn, so future runs can recall it.

The Scope setting controls the namespace under which turns are stored and retrieved. This determines what the agent "remembers" — whether it shares memory across all runs, within a single workflow, within a single execution, or only within a single step.

Memory Providers are configured separately in Settings → Memory Providers. Supported backends include Redis, SQLite, PostgreSQL, vector stores, and Mem0.

Configuration

Field	Status	Description
Memory Provider	Required	Select from the Memory Providers you have configured in Settings → Memory Providers. The provider determines the storage backend used for reading and writing turns.
Scope	Required	Controls the namespace key used to isolate memory. See the Scope Reference table below for full details.
Namespace	Optional	A custom string to further narrow the memory namespace. For example, you could use a user ID or a conversation thread ID to create per-user memory within a shared workflow.
Read Last N Turns	Optional	The number of the most recent conversation turns to inject into the agent's context before it runs. Default is 10. Setting this too high increases prompt length and API costs; setting it too low may cause the agent to forget relevant context.
Max Tokens	Optional	A token budget for the injected memory. If the retrieved turns exceed this limit, Flusso drops the oldest turns first until the history fits within the budget. Leave blank for no limit.

Scope Reference

Scope	Memory is shared across	Best for
`agent`	All runs of this workflow (per agent step key)	Long-running assistants that should remember context across multiple sessions, such as a personal productivity assistant or a customer support bot.
`workflow`	All runs of this workflow	Shared context that all agents in a workflow can contribute to and read from, regardless of which run produced the turns.
`run`	One single execution of the workflow	Multi-turn reasoning within a single run, where you need the agent to remember earlier steps in the same execution but start fresh each time.
`step`	One step within one run	Fully isolated per-step context. Rarely needed, but useful when you want each agent call to be completely independent even within the same run.

Output Data

No runtime output. The Memory node does not produce any output fields of its own. Its effect is applied automatically to the connected Agent node's context before and after the agent runs.

Example Usage

Building a persistent customer support assistant

This example connects a Memory node to an Agent so the assistant remembers the conversation history between sessions.

Ensure you have a Memory Provider configured. Go to Settings → Memory Providers and add a provider (e.g. SQLite for simple persistence or Redis for high performance). Note its name.
In the graph editor, add a Memory node from the AI & Agents sidebar category.
Open the Memory node's drawer. Select your Memory Provider. Set Scope to agent. Set Read Last N Turns to 20. In the Namespace field, enter {{ trigger.output.user_id }} to create a separate memory store per user.
Draw an edge from the Memory node's output port to the memory_in (Mm) port on your Agent node.
Run the workflow. On the first run, the agent has no history and answers from scratch. On subsequent runs for the same user, Flusso injects the prior conversation turns so the agent can refer back to what was discussed.

Tips & Notes

Use Namespace to separate memory per user. If your workflow serves multiple end users (for example, via a webhook that receives a user ID), always set the Namespace to a unique identifier such as {{ trigger.output.user_id }}. Without this, all users will share the same memory pool.
Token budget matters. Each injected turn costs tokens. A large Max History Turns combined with verbose responses can consume a significant portion of the model's context window before you even include the user's current question. Set a Max Tokens limit as a safety net.
Only one Memory node per Agent. Each Agent node accepts at most one memory_in connection. If you need memory from multiple scopes, handle the merging in a custom step before the agent runs.
Linear mode alternative. In linear mode, memory configuration is available directly in the Agent node's drawer under Memory Provider and Max History Turns. The Memory node is the graph-mode equivalent.

Related Nodes

Agent — the node this Memory node is connected to.
Model Config — the companion configuration node for specifying the AI model.
Memory Providers (Settings) — where you configure the memory backends available to this node.