All nodes/AI/Conversation Memory

Buffer Memory

Accumulates conversation history from this scenario's OWN past runs: empty on the first turn, filled as the conversation goes on. To read messages written in the chat before this scenario existed, use the Chat History node. Connects to the AI Agent's Memory input. LLM Response has no memory input — its conversation history comes from a Chat History node wired into its Message port. Storage scope: thread (between messages), session (within an execution) or call (one-off).

Try it

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 — its conversation history comes from a Chat History node wired into its Message port.

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

Outputs

Configuration