Memory retrieval and extraction

Memory retrieval prepares a generation with stored context. Extraction updates memory after the run and has a separate completion and failure lifecycle. Memory configuration defines the supported controls and ignored legacy flags.

Retrieval and extraction lifecycle

Use this sequence when the user asks why a just-mentioned preference has not appeared yet or why a later reply uses an earlier record. Separate retrieval, model generation and asynchronous extraction when explaining the outcome.

Memory integration runs in three phases around generation:

1. Before generation — the platform searches the user's memory store using the last user message (or searchQueryOverride) and retrieves the top searchTopK results above searchThreshold.
2. Attached to the latest user message — the current path inserts retrieved memories as a context block in the latest user message, despite the legacy injectAsSystemContext name. Relationship output is available only where supported by the deployment; enableGraph alone does not ensure it will be returned. A memory block can look like:

   [Relevant memories about this user:]
   - User is vegetarian and avoids gluten (remembered: Feb 15, 2025 at 10:00 AM UTC)
   - User prefers meals under 500 calories (remembered: Feb 20, 2025 at 2:30 PM UTC, updated: Mar 1, 2025 at 9:00 AM UTC)
   
   [Known relationships about this user:]
   - User → prefers → plant-based diet

3. After generation — the run's messages are passed to the extraction pipeline, which derives new facts and updates existing ones. The current extraction path is asynchronous. Its completion or success is not implied by a successful generation, and configured extraction still needs the appropriate data and spending permission.