Four Operation Tests Every Agent Memory Integration Needs

Test save, retrieve, correct, and remove as observable application behaviors before relying on agent memory. These are a practical acceptance set, not a claim that every provider exposes exactly four primitives. A service may use documents, memories, profiles, or other objects internally; the product still needs predictable outcomes across the lifecycle.

Save: accepted is not always searchable

Write a synthetic fact with a known source and authorized scope. Record the returned identifier and any processing state. Retry the same event and inspect whether it creates unintended duplicates. If indexing is asynchronous, wait for the documented readiness condition before judging recall.

Also test malformed input and an interrupted request. The application should know whether it can retry safely or needs to reconcile an uncertain result. A happy-path response alone does not establish a reliable write contract.

Retrieve: relevance and scope both matter

Ask a question that requires the saved fact and inspect the supporting evidence. Repeat with a paraphrase, an unrelated question, and a different user scope. The correct behavior includes useful matches, appropriate empty results, and no cross-user leakage.

Check the context actually sent to the model. A relevant search result can be dropped during assembly or crowded out by older material. End-to-end answer tests complement the retrieval check rather than replacing it.

Correct: the old fact must stop winning

Change the saved fact and repeat the question from a new session. Inspect source revisions, derived memories, profiles, and caches according to the integration's design. Include a temporary exception to verify that it does not permanently replace a default.

Define how conflicting sources are handled. The integration should not silently choose whichever statement happened to rank first when the product requires a confirmed or current value.

Remove: verify every eligible representation

Remove the fact using the documented lifecycle controls, then query again from the relevant clients and scopes. Check related source and derived representations rather than assuming one successful object deletion covers the whole pipeline.

Keep these fixtures small enough to run after dependency and configuration changes. The schema guide helps make the expected states explicit. To apply the acceptance set to a managed service, create a Supermemory test project and record the outcome of each operation before enabling memory for real users.