Skip to main content
AutoSage separates chat continuity from durable recall. Long conversations remain coherent through automatic compaction, while optional durable memory carries selected facts across separate conversations.

​
Three kinds of context

Compaction does not depend on durable memory. A long chat can retain continuity even when durable memory is disabled or temporarily unavailable.

​
Durable-memory settings

Durable memory is opt-in at the tenant level: A knowledge base can narrow the tenant policy further with kbMemoryMode:

​
Scope by caller

Always pass the same stable external_subject_id for the same end user. This lets their memory persist across chats while keeping it isolated from every other end user served by the key.
See Tenancy for the corresponding chat-ownership checks.

​
Recall lifecycle

1

Prepare chat context

Long histories are compacted when needed. Recent turns remain verbatim and the older summary preserves decisions and prior context.
2

Resolve the memory scope

AutoSage applies the tenant policy, knowledge-base mode, caller type, and external_subject_id before any recall.
3

Recall relevant facts

Relevant durable memories are selected from the resolved scope and added as context for the current message.
4

Generate the answer

Memory context is combined with recent history, the new message, and any knowledge-base or tool results.
5

Retain new facts

When retention permits it, useful facts from the turn can be stored for future conversations.
Recall and storage are best-effort. They never block the grounded answer if memory is unavailable, and response metadata reports only a memory_used boolean rather than exposing recalled memory contents.

​
Explicit memory

When durable memory is enabled and retention is explicit_only or automatic, users can store a fact directly with phrasing such as:
AutoSage confirms the memory operation instead of running a normal answer turn. Manage deletion through the memory management endpoints so changes are deliberate and scoped to the intended tenant or knowledge base.

​
Management endpoints

Memory management requires the corresponding tenant or knowledge-base access. Restricted-KB endpoints return isolated data only when that knowledge base uses kb_restricted mode. See the Tenant API, Knowledge-base API, and Memory product docs for configuration and management details.

​
Next steps

Durable memory

Choose retention and knowledge-base memory modes.

Prompt assembly

See where memory and compacted history enter a run.