SDK Overview

A TypeScript client for memory, pluggable across backends.

atomicmemory-sdk is a platform utility, not a framework. It gives application code a single, typed API for ingest, search, and context assembly, and it stays agnostic to which memory engine sits behind it. The same client can talk to a self-hosted atomicmemory-core, a Mem0 service, or a custom backend you wire yourself.

Three-point value prop

• Backend-agnostic via MemoryProvider. Every operation routes through the MemoryProvider interface. Swap atomicmemory-core for Mem0 — or a provider you write — with a config change, not a rewrite. Apps inspect provider capabilities at runtime and gracefully degrade when a backend does not support an extension (packaging, temporal search, versioning, etc.).
• Browser / extension / Node / worker-ready. ESM + CJS dual build, subpath exports, and WASM-based local embeddings via @huggingface/transformers. The same package runs in a Chrome extension, a Next.js app, a serverless handler, or a web worker.
• Client-side primitives for composition. The /storage, /embedding, and /search subpath exports ship standalone — StorageManager, EmbeddingGenerator, SemanticSearch. You can compose memory features directly from these without ever constructing the top-level AtomicMemorySDK. The SDK is a bundle of reusable parts, not a single mandatory object.

Deployment topologies

The first three topologies route through AtomicMemorySDK. The fourth does not — it composes the subpath exports directly. AtomicMemorySDK always requires a configured MemoryProvider; there is no backend-free mode of the top-level class. If you want to build with just the primitives, see Browser primitives.

Where to go from here

• Run through the Quickstart for a 5-minute install and first call.
• Read the Provider model to understand how the backend-agnostic story works in detail.
• If you are looking for the memory engine itself — the server, the HTTP API, the claim schema — start at the Core introduction.