All nodes/AI/Conversation Memory
Chat History
Reads THIS chat's conversation as a Messages array — including messages written before the scenario was built: the source is the saved chat messages keyed by (workflow_id, session), written by the platform itself. This is the primary way to give a bot memory of past turns; the memory nodes (Buffer/Window/Summary Memory), by contrast, only accumulate their own runs and are empty on the first turn. The last message of the array is the current one: the platform records it before the scenario starts. Wire the output into LLM Response's Message port (the model gets the whole conversation) or read it in a template. A node that takes this output must run after Chat History: either this output is the only thing connected to it, or draw a connection to it from the Success output. Bounded by limit. Works for both web chat and Telegram (bot turns are mirrored into the same table). By default it reads the current thread; you can override session_id.
Type in the graph: chat_history
Exec
An error output can be enabled to handle failures on their own path.
Try it
An LLM Response that sees the whole transcript
History feeds the Message port and reaches the model whole; the last message is the current question.
- Execute + Data
- Data
- LLM
Runs as pasted Before running, set: a model in the LLM node.
When to use it
Reach for this node when the conversation is needed as data rather than as agent memory:
to put the transcript into an LLM Response prompt, to count
something across past turns, to assemble a transcript for a report or an external system.
It is an ordinary executable step: it has a Run input and returns a Messages array in
chronological order, oldest first.
How it differs from the memory nodes (Buffer,
Window, Summary): those keep
the agent’s own tape — tool calls and tool results included — under their own key. Chat
History reads what the channel persisted: user messages and bot replies, keyed by scenario
and session. Web chat and Telegram share one source, because Telegram turns are mirrored
into the same table under a session id of the form tg:{chat_id}.
How it works
“Message limit” sets how many recent messages come back: 20 by default, 500 at most.
An empty “Session override” means the running thread. The field accepts a template, so you
can read another thread of the same scenario — for example
tg:{{ nodes.entry.data.telegram.chat_id }}.
The user’s message is persisted before the run starts, so the current question is already in the result, as the last element of the array.
When a run has no chat thread at all (webhook, schedule, manual run), the node returns an empty array rather than an error.
Common mistakes
- Giving an agent both this node and a memory node. The conversation reaches the model twice — once from memory, once as an input value.
- Expecting the agent’s tool rounds. The node reads the persisted transcript; tool calls never land there.
- Looking for a model-callable tool here. To let the agent decide when to look back, there is a separate Chat History Tool node — it attaches to the agent’s Agent extensions port instead of running as a graph step.
- Raising the limit “just in case”. Every message is input tokens on every run; 500 turns in a prompt cost noticeably more than twenty.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Inputinput | Execute + Dataexecute_data | — |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Messagesoutput | Datadata | messages |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Message limitlimit | integer | 20 | Maximum number of most-recent messages to return (chronological order). |
Session overridesession_id | string | "" | Optional thread/session id to read instead of the current conversation. Leave empty to use the running chat thread (web chat or 'tg:{chat_id}' for Telegram). Supports templates, e.g. tg:{{ nodes.entry.data.telegram.chat_id }}. supports templates |
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.