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:
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.Changing the model mid-thread
A conversation is bound to the harness and the provider it started with, because each CLI harness keeps its own session state and each provider needs its own credential. Picking a different model changes nothing until you send. On that send:- Same harness and same provider, for example two OpenRouter models: the thread continues and the message runs the model the picker shows.
- A different harness or a different provider: a fresh conversation starts, and the turns you have already had are carried into it as context the new model reads. The most recent turns are carried, up to about 4,000 characters, so a long thread arrives trimmed from its oldest end. You still see the previous messages in the chat, and the carried context is not shown as a dump in the transcript.
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.