Why Memory Works in One Chat but Fails in the Next

When an assistant remembers information within a chat but loses it in the next, check persistence and identity before changing the model. The first chat may still contain the answer in its message history. A new session needs a durable record, the correct retrieval scope, and an explicit path that brings the record into the prompt.

Prove the information exists outside the chat

Use a synthetic fact that cannot be guessed from general knowledge. Save it through the application's normal path, then inspect the resulting record or processing status. Record the source ID and scope. A successful model reply saying “I'll remember” is not evidence that a write occurred.

Wait for the documented processing state before testing retrieval. If ingestion is asynchronous, an immediate miss may reflect readiness rather than failed persistence. Keep that distinction visible in the test.

Trace identity across the session boundary

Compare the authenticated user, tenant, workspace, and memory scope in both sessions. A new conversation ID should not accidentally create a new user-memory namespace. Conversely, using one shared scope for every user can make recall appear reliable while exposing information across accounts.

Check mobile and web clients separately if they derive identifiers differently. Include anonymous-to-authenticated transitions, renamed workspaces, and multiple accounts. These are application identity problems even when the memory API behaves correctly.

Inspect retrieval and context assembly

Run a query in the intended scope and inspect the returned evidence. If the record is returned but the answer ignores it, investigate context assembly, ranking, prompt budget, or conflicting instructions. If it is absent, inspect filters, source status, and query formulation.

Record the actual context sent to the model using appropriately protected logs. A retrieval success metric does not prove the relevant item survived truncation or was included in the final request.

Test the full lifecycle from another session

Correct the fact, ask again from a fresh session, then remove it and repeat. Also ask from another user account. This distinguishes durable, scoped memory from a cached response or shared conversation history.

If the record should already be searchable, trace the missing-document path to separate processing from retrieval failures.

The history-versus-memory guide explains the boundary. To run the test with a managed service, create a Supermemory project and verify capture, readiness, scope, and prompt inclusion as separate checkpoints.