FFlow
RUStart free

All nodes/AI/Conversation Memory

Buffer Memory

Stores the full conversation history without limits. Connects to an AI Agent or LLM Response via link_memory. Storage scope: thread (between messages), session (within an execution) or call (one-off).

Buffer Memory▶S
Set historyMemory
Messages

Type in the graph: buffer_memory

ExecStateful

An error branch can be enabled (expose_error_output) to handle failures on their own path.

Try it

An agent that remembers the whole conversation

Memory attaches to the AI Agent over link_memory — it has no Run input of its own.

Entry
LLM▦
Buffer Memory▶S
AI Agent▶▦
Exit▶
  • Execute + Data
  • LLM
  • Memory
Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

Runs as pasted Before running, set: a model in the LLM node.

When to use it

Buffer Memory hands the agent the entire conversation: nothing is trimmed, nothing is compressed. Reach for it while the dialogue stays short and predictable — a two-turn helper bot, a step-by-step questionnaire, a graph you are still debugging. Once a thread lives for a while the context grows with it and every next turn costs more than the last: that is the moment to switch to Window Memory (a fixed tail) or Summary Memory (older turns compressed into text).

How it works

The node never runs on its own — it has no Run input. A consumer pulls it over link_memory, and there is exactly one such consumer: the Memory port of the AI Agent. LLM Response has no memory input at all — there you enable its own “Use Chat History” option or feed it a Chat History node.

After each turn the agent appends the whole round: the user message, the model’s replies, the tool calls and their results. So “twenty messages” for a tool-using agent is often two or three actual exchanges.

The store is keyed by node id + thread + memory type. Two consequences follow: two memory nodes in one graph do not share history, and swapping Buffer for Window in the same spot starts the history over — the old messages stay in the database, but under a different key.

The Scope field decides how long a record lives: thread survives across chat messages and is stored in the database; session lasts one execution; call starts empty every time.

Common mistakes

  • The node sits on the canvas unconnected. On its own it does nothing: draw the link from its Memory output to the agent’s Memory port.
  • Expecting history where there is no chat thread. A webhook, a schedule or the manual Run button has no thread, so thread memory falls back to the execution id — it behaves like session.
  • Confusing memory with chat history. The chat panel shows what the channel persisted; agent memory is a separate store with its own key. Delete the node or change its id and the agent forgets, while the transcript in the panel stays exactly where it was.
  • Turning on “Set history from input” just to read. The messages_in port overwrites the store completely. To inspect the current state, enable “Messages output” instead.

Inputs

PortWirePayloadNotes
Set historymessages_inExecute + Dataexecute_datamessages

shown when overwrite_from_input = true

Outputs

PortWirePayloadNotes
MemoryoutputMemorylink_memory—
Messagesmessages_outDatadatamessages

shown when expose_messages_output = true

Configuration

FieldTypeDefaultDescription
Messages outputexpose_messages_outputbooleanfalse

Show a data output port that emits the current stored messages.

Set history from inputoverwrite_from_inputbooleanfalse

Show a Messages (ED) input port whose firing fully overwrites the stored history, plus a 'History set' exec output that fires once the history is written.

Scopescopestringthread

thread: persists between chat messages · session: lives for one execution · call: fresh each time

Options: thread — Thread, call — Call, session — Session

Shared fields

Every node has these three — the platform adds them, not the node author.

  • expose_error_output — When enabled, show an execution output to connect nodes that run if this step fails.