“Oh wow that is awesome.” Dhravya Shah, founder of Supermemory
The problem
Every AI memory backend ships a different SDK. Moving from Supermemory to Letta to another backend usually means rewriting document add, search, forget, and list workflows even when the product behavior is conceptually the same.The approach
MemSDK freezes a proven interface instead of inventing a new one. It provides:SupermemoryInterfaceas a type-level contract.- Zod schemas for runtime request validation.
- Adapters that prove the contract can map to real backends.
Repositories
Installation
Bothmemsdk and its adapters are distributed directly from GitHub. They are
not currently published to the npm registry.
Install the core package with any npm-compatible package manager:
prepare, then expose
compiled ESM entrypoints and TypeScript declarations from dist.
Runtime support
memsdk is plain ESM compiled with tsc. Zod is the only runtime dependency,
and the package declares no engines constraint. Runtime support therefore
comes down to how the package is resolved, not runtime-specific code:
Because
memsdk is primarily a TypeScript contract plus Zod schemas, browser
and edge use should go through a bundler today. Direct <script>/CDN usage is
not a supported distribution path yet. Publishing to the npm registry would
unblock Deno npm: specifiers, browser CDNs, and edge registries from a single
artifact.
Adapters such as memsdk-letta depend on backend SDKs and should run
server-side unless browser bundling has been validated for your app.
Usage
Use the core contract to write backend-agnostic app code:search is a callable top-level method on the contract. The legacy
search.documents, search.execute, and search.memories variants are
deprecated; use client.search() for v4 memory search.