Supermemory AI: Prove Memory Is Ready, Scoped, and Current

Supermemory AI is a memory and context layer for agents: it ingests conversations and documents, derives memories, supports retrieval, and maintains profiles. The operational question is narrower than “did the API accept my write?” A useful memory is ready only when the source finished processing, the expected fact can be recalled from the correct container, and the returned version is still current. That distinction matters because Supermemory documents two separate timelines. A document reaching done means its document path is searchable. With the default dynamic dreaming mode, memory extraction can continue after that status. An operator who turns done into a green memory health signal can therefore report success before the agent can recall the fact it needs. The practical default is to keep dynamic for normal production ingestion, then verify recall before allowing a memory dependent action. Use instant only when the next step genuinely requires the graph fact immediately, and account for the extra operation documented by Supermemory. In both modes, preserve containerTag , customId , timestamps, and content free evidence hashes in one receipt. A green document status is not a green memory verdict Supermemory's current pipeline documentation names the document stages: queued, extracting, chunking, embedding, indexing, and done. It also says that the same input can yield three different outputs: document chunks for source grounding; graph memories for extracted facts and temporal updates; a profile for always on context. Those outputs answer different questions. A successful document search proves that indexed source material is available. A memory search proves that a derived fact is retrievable. A profile response proves that a selected summary is available. None of the three, by itself, proves the others. The official quickstart makes the timing boundary explicit. add returns while processing is asynchronous. With dreaming: "instant" , the tutorial waits for the document to reach done before checking memories and profiles. With the default dynamic mode, document RAG can be ready while memory extraction is still batching related material. Turn that into a five field receipt rather than a single boolean: Evidence What it proves What it does not prove ingestStatus: done The document path finished processing The expected graph memory is already retrievable in dynamic mode recall query ran A read attempt occurred The returned fact is the expected or current one expected hash matched The content free canary corresponds to the expected fact The result came from the right tenant or project container matched The retrieval stayed inside the intended isolation scope The fact has not been superseded current version checked The returned fact is the version the workflow should use The agent completed its downstream task Hash only a synthetic canary created for the test. Do not hash private user memory and call that anonymous: predictable values can still be guessed. Keep production prompts, retrieved content, API keys, and user facts out of the health record. Build a memory receipt that can represent waiting The important state is not only healthy or broken. dynamic dreaming deliberately groups related documents into coherent units, so a short recall gap after document completion can be legitimate waiting. The same miss after an agreed observation window is a failure. In instant mode, a miss after done deserves immediate investigation because the documented purpose of that mode is prompt availability after processing. A compact evidence record can look like this: The observation window is your operating policy, not a Supermemory service level promise. Measure it for your content types and workload. A short conversation, a long video, and a connector resync do not have interchangeable processing distributions. The classifier used for this article applies the following precedence: I replayed seven cases through that order: queued input, document only completion, permitted dynamic lag, missing instant memory, cross container retrieval, a superseded fact, and a healthy receipt. Only the final case was safe to use. The distinction between memory waiting and memory missing prevented a normal batching delay from becoming an incident, while the separate recall unverified state prevented document completion from being mislabeled as memory readiness. This artifact is intentionally a classifier, not a live Supermemory probe. It trusts the normalized evidence supplied by your adapter. Validate the adapter independently, especially the scope and version fields. Test scope and freshness with paired canaries Supermemory describes containerTag as a hard isolation boundary and recommends a stable customId for content that will be updated. Those two identifiers should be part of every memory health test. Create two synthetic containers that can never be mistaken for real users: 1. write a unique, non secret canary fact to container A under a stable customId ; 2. write a different canary to container B; 3. wait according to the chosen dreaming mode; 4. search A for A's canary and verify its hash; 5. search B for A's canary and require no matching result; 6. update A's fact under the same logical identity; 7. verify that retrieval selects the new fact and does not promote the superseded value; 8. restart the calling agent or begin a fresh session, then repeat the read. The negative query is as important as the positive one. A correct answer from container A does not prove isolation. You need evidence that container B cannot retrieve A's canary. Likewise, retrieving any related memory after an update does not prove temporal correctness. The returned record must correspond to the current expected version. Do not run destructive forget or container deletion tests against a real user's scope. Supermemory exposes memory update and forgetting behavior, but a scheduled health check should use dedicated synthetic containers with an explicit cleanup policy and limited credentials. If cleanup fails, record it as its own issue rather than hiding it inside recall health. Route each failure to the smallest repair A useful verdict should point to one bounded next action: State First action processing Keep waiting and preserve the original document ID memory waiting Recheck after the measured dynamic window; do not re ingest yet ingest failed Inspect the document failure and input type before retrying recall unverified Run the synthetic recall check; do not declare memory healthy memory missing Compare dreaming mode, processing time, query, and container before one bounded retry scope unverified Stop memory dependent actions until the adapter can prove the intended container scope leak Treat as a high severity isolation failure and block use of the result stale or wrong memory Inspect update identity and version history; do not overwrite blindly ready Allow the memory dependent step, then verify its actual outcome separately Re ingestion is not a universal repair. If the original write succeeded and memory extraction is merely waiting, another write can create duplicate work and make temporal diagnosis harder. Switching every write to instant is also not a neutral fix: the documentation presents it as a latency trade off with an extra billed operation, while dynamic is the production default for grouping related material. Finally, memory readiness is still not task success. An agent may retrieve the correct preference and then ignore it, call the wrong tool, or fail to produce the deliverable. Keep a separate outcome receipt for the action that consumed the memory. Sidewisp's relevant product direction is to make memory and context health visible alongside agent reachability, tool access, progress, and outcomes. Sidewisp is currently in private preview. Its production monitoring engine, host adapters, and recovery executor are not generally shipped, so this article is an operator run pattern rather than a claim that Sidewisp currently audits Supermemory installations.