atomicmemory

AtomicMemory

Inspectable, portable semantic memory for agents and applications.

AtomicMemory is a memory layer you embed where your AI code already runs. Capture context, ground generations in prior interactions, and carry knowledge across sessions — from a direct SDK call, a CLI, an MCP server, a framework adapter, or a host plugin. Local-first where supported, hosted where convenient, and designed so the choice can change later without rewriting your application.

Most memory products ask you to trust a hosted black box with the layer that decides what an AI believes about your users. AtomicMemory takes the opposite position: the interface should be portable, the engine should be inspectable, and the memory system should be able to revise itself when facts change.

This repository is the public source of truth for the AtomicMemory JavaScript / TypeScript packages, framework adapters, host plugins, and public smoke tests.

Docs: docs.atomicstrata.ai

Field note: The AI Memory Industry Has A Black Box Problem

Headline Results

AtomicMemory v66 is cost-Pareto SOTA on BEAM-100K, BEAM-1M, and LoCoMo10 under matched methodology against published competitors. On BEAM-10M it matches the strongest published Mem0-new result while leaving Hindsight-scale temporal retrieval as the known open frontier.

Benchmark	AtomicMemory v66	Position	Cost/Q	Sample
BEAM-100K lenient	0.7375	Parity with Hindsight at 0.75	$1.26	n=80
BEAM-1M lenient	0.6625	Cost-Pareto SOTA; +0.022 vs Mem0 paper	$0.083	n=80
BEAM-10M lenient	0.4875	Parity with Mem0-new at 0.486	$0.081	n=80
LoCoMo10 GPT-4o-mini binary	0.8396	Cost-Pareto SOTA; +0.171 vs Mem0 paper	$0.066	n=1540

These results put AtomicMemory at or near the published ceiling in each reported category while preserving the lower-cost operating profile that matters for real applications. Reproducibility artifacts and harness details will be published with the benchmark materials.

Why AtomicMemory

• Portable: a single memory protocol consumed by direct SDK calls, CLIs, the MCP server, framework adapters, and host plugins. The same memory store serves a LangGraph agent, a Claude Code session, and a custom Vercel AI application without re-implementing capture or retrieval semantics.
• SDK-agnostic: every adapter is built on the same SDK. Adapters are conveniences, not gatekeepers. You can drop down to the SDK at any time and keep the same data, indexes, and retrieval behavior.
• Inspectable: Core is open source, self-hostable, and built around explicit mutation decisions rather than an opaque hosted opinion.
• Correction-aware: memory is not just append and recall. Real products need supersession, clarification, deletion, no-op decisions, lineage, and trust-sensitive revision when users change their mind.
• Model-surface portable: the SDK lets applications swap memory backends; Core separates embeddings, extraction, mutation, reranking, retrieval packaging, and evaluation so the memory engine is not frozen to one model vintage.
• Local or hosted, your choice: the core engine runs locally for privacy-sensitive workloads. The hosted profile is available where it makes sense and is marked clearly in the package matrix below. There is no capability cliff between the two.
• No lock-in: package APIs are stable and semver-disciplined. Migrating between direct SDK use, adapters, and host plugins is documented and does not require re-ingesting your data. You own your memory store.

What This Repository Provides