All nodes/AI/Conversation Memory
Window Memory
Stores only the last N messages of the dialogue (sliding window). More predictable in context size than Buffer Memory. Configured via window_size.
Type in the graph: window_memory
ExecStateful
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Try it
A chatbot with a ten-message window
Memory attaches to the AI Agent over link_memory; the tail length comes from Window Size.
- Execute + Data
- LLM
- Memory
Runs as pasted Before running, set: a model in the LLM node.
When to use it
Window Memory keeps only the last N messages. Context size stops depending on how old the conversation is, and — unlike Summary Memory — no extra model calls appear. That makes it the sensible default for a chatbot that runs for months and does not need to recall how the conversation started. When the whole dialogue matters, use Buffer Memory instead.
How it works
The node never runs on its own: it has no Run input, a consumer pulls it over link_memory.
There is exactly one consumer — the Memory port of the
AI Agent.
Before every turn a tail of Window Size messages goes to the model (10 by default, 1 to 200 allowed). Anything older is dropped — and dropped for good: after the turn the agent stores the trimmed tail plus the new round, so the old messages leave the store as well. This is not “show the model N messages out of a full archive”.
The window counts every message of a round, not just human and bot lines: a tool call and its result are messages too. For a tool-using agent a ten-message window may hold one or two exchanges.
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
- Reading the window as exchanges. Ten messages is five question-answer pairs at best, and noticeably fewer once tools are involved.
- Attaching both a window and a Chat History node to the same agent. The conversation reaches the model twice: once from memory, once as an input value.
- Leaving the node unconnected. Draw the link from its Memory output to the agent’s Memory port; without it the node does nothing.
- Expecting history where there is no chat thread. A webhook, a schedule or the manual
Run button has no thread, so
threadmemory falls back to the execution id — it behaves likesession.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Set historymessages_in | Execute + Dataexecute_data | messages | shown when overwrite_from_input = true |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Memoryoutput | Memorylink_memory | — | |
Messagesmessages_out | Datadata | messages | shown when expose_messages_output = true |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Messages outputexpose_messages_output | boolean | false | Show a data output port that emits the current stored messages. |
Set history from inputoverwrite_from_input | boolean | false | 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. |
Scopescope | string | thread | thread: persists between chat messages · session: lives for one execution · call: fresh each time Options: |
Window Sizewindow_size | integer | 10 | Number of most recent messages to include |
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.