Skip to main content

Using the Mem0 backend

Mem0Provider is the SDK's HTTP client for Mem0. It demonstrates the backend-agnostic design in practice: the same SDK, the same methods, a different engine behind the interface.

Support status. Verify the current support stance with the project before building on this path. Mem0 compatibility is exercised in tests and works for the core operations, but Mem0Provider's position in the roadmap is an open question. Prefer atomicmemory-core when you need a first-class path.

Wire it up

import { AtomicMemorySDK } from '@atomicmemory/atomicmemory-sdk';

const sdk = new AtomicMemorySDK({
userAccounts: { /* see Scopes and identity */ },
context: {
providers: {
default: 'mem0',
mem0: {
apiUrl: 'http://localhost:8000',
apiKey: process.env.MEM0_API_KEY,
timeout: 30000,
},
},
},
});

await sdk.initialize();

Capability differences

Mem0Provider implements the six core operations (ingest, search, get, delete, list, capabilities) plus the health extension. It does not implement:

  • package — context packaging with token budgets
  • temporal — point-in-time search
  • versioning — per-memory history
  • updater — in-place updates
  • graph, forgetter, profiler, reflector, batchOps

Code that calls sdk.package() on a Mem0-backed SDK will raise UnsupportedOperationError. Use the capability-probing pattern from Capabilities to handle this gracefully:

const { extensions } = sdk.capabilities();

if (extensions.package) {
const pkg = await sdk.package(request, site);
injectContext(pkg.text);
} else {
const page = await sdk.search(request, site);
injectContext(formatFallback(page.results));
}

When to pick Mem0

  • You're already invested in Mem0's hosted platform or OSS deployment
  • You want to compare memory engines behind a single client
  • You're migrating from Mem0 and want a transition path without rewriting application code

For greenfield deployments where packaging, temporal queries, and versioning matter, atomicmemory-core is the supported first-class path.

Next