Skip to main content
Agents persist their chat history. The Conversation Key field (under Advanced in the agent’s config panel) controls which history a run continues: same key, same conversation. All six harnesses persist history, including the CLI agents.

​
How keys work

  • Histories are scoped to the workflow and the agent node, then to the key. Two agents never share a conversation, even with the same key value.
  • If no key is set, each manual run or chat session stands on its own history thread.
  • The key can be a static string or a reference like {{nodeId.field}}, so you can derive it from upstream data, for example one conversation per customer ID.

​
Channel triggers set the key automatically

When a channel trigger is wired directly into the agent, the fired event supplies the key:
TriggerAutomatic key
Telegram messageThe chat ID, so each chat is its own conversation
Slack messageChannel + thread for channel messages, channel for DMs, so each thread is its own conversation
AlarmThe key captured when the agent scheduled the alarm
A fired trigger’s key takes priority over the configured Conversation Key, so a Telegram agent with a fallback key still keeps per-chat threads.

​
Resetting a conversation

Change the key. A new value starts a fresh history; switching back to an old value resumes that thread. There is no separate clear button: the key is the identity of the conversation.
The filesystem node has a Per Conversation Key volume mode that gives each conversation its own isolated storage, useful when each user of a channel agent needs separate files.

​
Next steps

Channel agents

Threaded Slack and Telegram agents that remember each chat.

Data references

Reference syntax for dynamic conversation keys.