A TypeScript Memory Layer: Define the Contract Before the SDK

A TypeScript memory layer benefits from a small application contract that separates identity, retrieval, and writes from any particular SDK. Types can make boundaries easier to understand, but runtime authorization and provider behavior still need validation.
Start with the operations your application requires, not a universal interface that pretends all memory providers have identical semantics.
Keep identity out of the model's control
Resolve tenant and user identity from the authenticated application context. Pass a validated scope to the memory adapter. A tool may request a search question, but it should not be free to choose another customer's namespace.
Represent conversation identity separately from user identity. A new thread can belong to the same user without inheriting every message from the previous thread. The AI SDK integration guide shows that separation in an existing TypeScript workflow.
Return evidence and status, not just text
The retrieval boundary should distinguish a successful empty result from a timeout or rejected request. Return evidence identifiers and versions alongside the text used for the answer. Keep provider-specific details where they are necessary to explain behavior rather than hiding them behind a misleading generic success flag.
At the generation boundary, allocate context deliberately. Limit the number and size of passages, preserve provenance, and treat retrieved instructions as untrusted source content.
Give write operations explicit meaning
Separate capturing a source event, correcting a source, forgetting a memory, and deleting a document. These are not interchangeable operations. A method called “remove” is unhelpful if callers cannot tell which records remain available through other paths.
Retain source event IDs across retries and record the provider's accepted ID. Decide which writes happen before the next response and which run in the background. Expose readiness when an accepted write is not immediately searchable.
Test the adapter and the provider separately
A fake adapter can verify scope forwarding, error handling, and call order. It cannot prove extraction quality or remote deletion behavior. Run a configured provider test with a fictional record, another user, a correction, and a removal request.
For an OpenAI application, compare the pre-request and tool-based integration boundaries before choosing the adapter contract.
Supermemory's SDK documentation defines its supported client. Get an API key and connect one application route first; retain the contract tests as the integration expands.