All nodes/AI/Conversation Memory
Chat History
Loads the recent history of the current conversation as a Messages array, bounded by a message limit. The source is the saved chat messages keyed by (workflow_id, session). 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 branch can be enabled (expose_error_output) to handle failures on their own path.
Try it
An LLM Response that sees the whole transcript
History feeds the Message port; the LLM Response node must have "Use Chat History" enabled.
- 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 workflow
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 workflow — 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 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 |
|---|---|---|---|
Runinput | 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.