Skip to main content
Session memory is a rolling buffer that accumulates per conversation, automatically. The Agent doesn’t do anything explicit: every chat message goes in, and older turns get folded into a running summary once the window fills.

​
When to use it

  • Chat-style Agents: for the “we talked about X earlier” continuity
  • Multi-turn tasks: decisions made in an earlier turn need to stick for later ones
  • Short-lived conversation history: mostly cleaned up when the session ends
For long-lived facts or team knowledge, use Wiki or Index, not Session.

​
Creating one

Memory → New space → Session (chat) creates one immediately.

​
The detail page

  • Conversations tab: list of conversations (scopes) on the left. Pick one and the right pane shows two blocks:
    • Rolling summary older turns folded into a summary. If the summary itself was re-summarised, an L1 / L2 badge shows the recursive depth.
    • Recent turns the verbatim tail still intact, in chronological order.
  • Settings tab: covered below.
Session has no Log tab the conversation itself is this space’s log. The Conversations tab is read-only; you don’t delete or edit conversations from here.

​
What you configure in Settings

Basics rename the space. Flow binding bind to a specific Flow, or leave unbound and attach per-Agent. Scope which request parameters partition conversations. Session memory typically uses flow_id + thread_id. See Scoping. Access (optional) partition key + required-permissions gate.

​
Session buffer

The Session-only section that controls how conversations are stored and kept.
  • Store the storage backend:
    • redis: hot and volatile. Fast, lost on restart. For short conversations
    • postgres: durable. Survives beyond the session
    • both (default): Redis for fast reads, Postgres for durability
  • Recent window how much of the recent tail stays verbatim (before summarising):
    • Basis: turns or tokens
    • Size: how many to keep
  • Summarize when on, older turns are folded into a rolling summary before the window overflows.
    • Trigger fraction of the window budget (0–1, default 0.8 = triggers at 80% full)
    • Recursive summary if the summary itself overflows, summarise the summary. For very long conversations
  • Trigger message (optional) a short note dropped in the conversation when a summary fires. E.g. “Earlier context summarized.”

​
Summarizer

Appears when Summarize is on. Configures the agent that produces the rolling summary.
  • Model the model that runs the summary. Pick from workspace providers. Blank uses a low-cost default.
  • Summarize prompt (optional) customise how the summary is written. Example: “Keep every decision and open question; drop chitchat.”
Unlike Wiki/Index, Session has no policy prompt, multimodal, or background-writes options Session doesn’t curate facts; it just summarises.

​
Attaching to an Agent

In the flow builder, open the Agent, go to the Memory tab, and click Add memory. Session typically scopes by thread_id, so make sure the trigger (API/webhook) passes threadId. The same threadId continues the same conversation.

​
How conversations get written

Nothing to do: every turn’s user input, Agent response, and tool calls land in this space automatically. Summarisation kicks in when the window fills per the settings above.

​
Cleaning up conversations

Session isn’t designed for long-term data, so Wiki/Index concepts like supersede, importance decay, and per-item delete don’t apply. If Store is redis (or the Redis layer of both), sessions clear naturally when they end or Redis restarts. For anything held in postgres, use admin tools or nora memory to clean up by scope.