Supermemory is positioning the right problem very clearly: memory is fragmented across Cursor, Claude, VS Code, Claude Code, Cline, etc., and MCP can make recall portable.
One observability/debugging gap I keep seeing in shared-memory workflows is: after a cross-client recall happens, what privacy-safe evidence can a user or maintainer inspect/share without dumping the raw memory, prompt, transcript, or private repo text?
For example, when someone says “Claude did not remember the PDF I added in Cursor” or “the wrong project memory was retrieved”, the useful artifact is not the memory body. It is a small receipt of what the memory layer returned and whether the client/harness loaded it.
A minimal receipt shape could be:
memory.search.returned
memory.provider = supermemory
client.name = cursor | claude-code | vscode | ...
project.id_hash
query.hash # not raw query by default
result.count
result.ids_hash
result.score_bucket[]
result.content_hash[] # hash of returned chunks, no raw memory text
snapshot.id/hash
latency_ms
context.input.loaded # emitted by client/harness if it entered the session
source.uri = supermemory://...
delivered.hash
estimated_chars
activation = mcp_search | automatic_recall | manual
duplicate.suppression_policy
That separation matters because the MCP server can prove “these memories were returned”, while the client/harness proves “this context actually entered the model/session”. Both can stay privacy-first.
Why I think this is useful:
- user bug reports can include receipts without exposing private memories;
- maintainers can distinguish “search returned nothing” vs “client did not load returned memory”;
- teams can audit cross-client memory usage without enabling raw prompt/memory logging;
- it creates a bridge to OpenTelemetry-style agent traces without making Supermemory responsible for the entire agent runtime.
I have a small public fixture exploring this general receipt pattern here, if useful as prior art: https://github.com/caioribeiroclw-pixel/pluribus/tree/main/examples/context-input-evidence
The concrete ask is small: would Supermemory consider an optional debug/export mode that emits privacy-preserving memory search/result receipts, or is this better as an external wrapper around the MCP client/server boundary?
Supermemory is positioning the right problem very clearly: memory is fragmented across Cursor, Claude, VS Code, Claude Code, Cline, etc., and MCP can make recall portable.
One observability/debugging gap I keep seeing in shared-memory workflows is: after a cross-client recall happens, what privacy-safe evidence can a user or maintainer inspect/share without dumping the raw memory, prompt, transcript, or private repo text?
For example, when someone says “Claude did not remember the PDF I added in Cursor” or “the wrong project memory was retrieved”, the useful artifact is not the memory body. It is a small receipt of what the memory layer returned and whether the client/harness loaded it.
A minimal receipt shape could be:
That separation matters because the MCP server can prove “these memories were returned”, while the client/harness proves “this context actually entered the model/session”. Both can stay privacy-first.
Why I think this is useful:
I have a small public fixture exploring this general receipt pattern here, if useful as prior art: https://github.com/caioribeiroclw-pixel/pluribus/tree/main/examples/context-input-evidence
The concrete ask is small: would Supermemory consider an optional debug/export mode that emits privacy-preserving memory search/result receipts, or is this better as an external wrapper around the MCP client/server boundary?