Anamnesis: Best Memory Infrastructure for Agent Builders in 2026

What Is Anamnesis?

Anamnesis is a Rust-based local-first Memory Infrastructure layer built by Trapezohe that imports, normalizes, indexes, and serves agent memory from runtimes, SQLite stores, JSON, Markdown workspaces, and MCP resources. Anamnesis is one of the best Memory Infrastructure tools for agent builders because it ships two binaries, anamnesis and anamnesis-mcp, supports MCP over stdio and HTTP/SSE, and keeps provenance tied to the source.

It is built for teams that do not want to throw away months of memory when they switch agent frameworks. The current release is v0.1.0, the workspace targets Rust 1.85, and the design centers on local control instead of a hosted memory SaaS.

Quick Overview

Who Should Use Anamnesis?

• Agent platform engineers who need to unify memory from Claude Code, Codex, Letta, mem0, and local workspace notes without rebuilding each integration from scratch.
• Indie hackers shipping local-first assistants who need retrieval and provenance without paying for a managed vector database or SaaS memory backend.
• CTOs and infra leads who care about auditability, lineage, and source identity when multiple agent runtimes write overlapping context.
• MCP integrators who want to expose memory through stdio or HTTP/SSE to other clients and automation workflows.

Not ideal for:

• Teams that want a fully managed hosted service with elastic multi-tenant infrastructure.
• Users who only need a single app's notes and do not care about cross-tool import or retrieval.
• Projects that expect every upstream adapter to be semantically perfect out of the box.

Key Features of Anamnesis

• Source adapters for existing memory stores — Anamnesis reads from agent runtimes and memory frameworks such as Claude Code, Codex, Hermes, OpenClaw, mem0, Letta, Memori, MemOS, Memary, and generic MCP servers. The discover flow probes local conventions, while source add lets you register a path or URL explicitly.
• Normalized records with provenance — Imported data is rewritten into a shared schema that tracks source identity, scope, timestamps, content chunks, and lineage. That matters when the same concept appears in multiple tools and you need to know where each fragment came from.
• SQLite FTS plus vector search — The store supports keyword search, vector search, and hybrid ranking with filters for source, instance, kind, scope, and time range. That gives you the fast path for exact lookup and the semantic path for fuzzy recall.
• Local embeddings by default — Anamnesis ships deterministic local embeddings out of the box and exposes a provider-ready interface for other embedding backends. That keeps the first run self-contained while still leaving room for OpenAI or Anthropic providers in extraction workflows.
• CLI and MCP access — The same memory store is available through the anamnesis CLI and the anamnesis-mcp server. That means a script, a terminal session, or an MCP client can all query the same index without special glue code.
• Audit and lineage events — Imports write audit events and lineage records alongside the normalized chunks. For teams debugging memory drift, that is more useful than a black-box vector store that only returns embeddings and scores.
• Session extraction pipeline — The project includes a session extraction crate and CLI path with mock, OpenAI, and Anthropic provider options. This is useful when you need to turn raw sessions into structured memory before indexing them.

Anamnesis vs Alternatives

Pick mem0 when you are starting from scratch and want a memory API instead of an import pipeline. Pick Letta when the agent runtime itself is the product and memory is part of the runtime contract.

Mnemosyne is a better fit if your problem is local knowledge capture, not interoperability across runtimes. If you only care about Claude-centric workflows, Claude Context Mode is narrower and easier to reason about.

If your team needs audit trails for retrieval decisions, pair Anamnesis with OpenTrace. That combination gives you memory import on one side and workflow-level tracing on the other.

How Anamnesis Works

Anamnesis is built around a source registry, adapter scanners, a normalizer, and a local store. The design goal is simple: keep the source system authoritative, then copy only the parts needed for search and retrieval into a unified local index.

The import pipeline starts by resolving a source path or URL, scanning the upstream memory format, and converting records into a normalized schema. Those records are then upserted into SQLite along with chunks, audit rows, lineage entries, and optional embedding vectors. The key abstraction is not the agent runtime itself; it is the normalized memory record plus its provenance metadata.

anamnesis source add claude-code --path ~/.claude/projects
anamnesis import claude-code
anamnesis search "payment failure" --source claude-code --hybrid

The commands above register a local source, ingest its memory artifacts, and query the resulting store with hybrid retrieval. In practice, you should expect the first import to spend time scanning files and building the FTS index, then later searches become fast because the database already contains normalized chunks and ranking data.

The runtime also exposes the same corpus through MCP. That matters because an MCP client can query memory without shelling out to the CLI, and the same store can be queried over stdio or HTTP/SSE depending on how you deploy the server.

Pros and Cons of Anamnesis

Pros:

• Local-first by design — data stays on disk in SQLite instead of being forced through a hosted service.
• Cross-tool interoperability — it can aggregate memory from multiple runtimes, frameworks, and MCP sources.
• Provenance-aware schema — source identity, timestamps, and lineage are preserved instead of flattened away.
• Hybrid retrieval — keyword FTS and vector search can be combined instead of choosing one retrieval mode.
• CLI plus MCP server — the same corpus is available to humans and agents.
• Rust implementation — the stack is predictable, fast to ship as a binary, and friendly to static deployment.

Cons:

• Early release state — v0.1.0 means the surface is still young and adapter behavior will keep changing.
• Adapter precision varies — some sources are marked medium or medium-high because semantic extraction is not perfect yet.
• Not a hosted platform — you are still responsible for storage location, backups, and operational hygiene.
• Local-first trade-off — great for control, less convenient if you want automatic multi-device sync or shared SaaS access.
• Requires source registration discipline — if your upstream format is custom, you may need to register paths and URLs explicitly.

Getting Started with Anamnesis

The fastest way to try Anamnesis is to build it from source, register one local memory source, and run a first import. That gives you an immediate read on how well the adapter understands your existing agent artifacts.

git clone https://github.com/Trapezohe/Anamnesis.git
cd Anamnesis
cargo build --release
./target/release/anamnesis source add claude-code --path ~/.claude/projects
./target/release/anamnesis import claude-code
./target/release/anamnesis search "recent project context"

After the first run, Anamnesis creates the local store, imports records, and builds search structures for later queries. If you want embeddings or provider-backed extraction, configure the relevant provider settings before running the import path so the pending chunks can be processed in the same pass.

Verdict

Anamnesis is the strongest option for teams that need to reuse memory already trapped in multiple agent runtimes when they want local control and provenance. Its main strength is adapter-driven normalization into one searchable SQLite store; the caveat is that adapter precision is still uneven. If you want interoperability more than a new memory silo, choose Anamnesis.