rmbr

rmbr

Give your agent memory and knowledge. One file, three lines, no server, no API key.

rmbr ("remember", vowels deleted) is an embedded, local-first memory + retrieval engine for AI agents and LLM apps — what SQLite is to Postgres, rmbr aims to be to hosted memory services.

v0.2.7. pip install rmbr gets you a working library: Memory, Index, Policy, MCP support, an optional HTTP server, PDF/DOCX ingestion, and framework adapters for LangChain/LlamaIndex/LangGraph/mem0 (all below), all implemented and tested — see docs/PLAN.md and docs/ARCHITECTURE.md for the design.

Start with three lines, then reach for exactly as much more as you need — nothing below is required to use the part above it:

• `Memory` — durable, searchable notes your agent chooses to keep, namespaced per agent
• `Index` — hybrid (keyword + semantic) search over your own docs, for RAG
• `Policy` — deny-by-default access control, so one agent can't read another's memory unless you explicitly allow it
• Framework adapters — LangChain and LlamaIndex retrievers, a real LangGraph BaseStore, a mem0-API-compatible drop-in, raw OpenAI/Anthropic tool-calling export
• An MCP server, for any MCP client (Claude Desktop, Claude Code, Cursor, ...) — *optional*
• An HTTP server, for serverless functions or anything that'd rather curl it than hold a connection open — *also optional*

If you only ever use the first three, that's not a "basic" use of rmbr — that *is* rmbr for most people. The server modes exist for the specific cases they solve, not because you're expected to grow into them.

Contents: Why · Quickstart · Multi-agent isolation · MCP support · HTTP support · Alternatives · Performance · Roadmap

Why

Agents can already "remember" things across restarts — a CLAUDE.md, a system prompt, a JSON file on disk. That's not new, and rmbr isn't claiming otherwise.

What breaks is what happens as that file grows. Every fact in a static context file costs tokens on *every single call*, whether it's relevant to the current task or not — so it either stays small (a few dozen hand-curated notes) or turns into noise nobody's cheaply reading anymore. There's no ranking: the agent gets the whole file, or nothing, never just the 5 facts that actually matter for this turn. A static file gets more expensive and less useful the more the agent learns; a searchable memory gets more useful and stays the same cost per call. mem.recall(query) returns the *k* most relevant memories out of however many thousand you've accumulated — that's the actual gap between "an agent that can write to a file" and "an agent with memory."

The other place people get burned: rolling this yourself. Chunk text, embed it, throw it in a vector store — that's a legitimately easy weekend project (this one started that way too). What's easy to get wrong in that weekend project: real hybrid search (most ship vector-only or keyword-only and never notice), an embedding cache (so you're not re-embedding — and re-paying for — the same text on every call), and, if there's more than one agent involved, *safe* isolation between them. Most hand-rolled or framework-provided multi-agent memory either shares one blob every agent can read and write, or scopes access via a namespace/user_id parameter the *calling model itself* supplies — which a prompt injection can simply ask to change. rmbr's MCP tools don't expose that parameter at all; there's no field for an injected instruction to fill in.

So: rmbr exists for the gap between "stuff it in a system prompt" (doesn't scale past a few KB) and "stand up real infrastructure" (Docker, a graph database, a hosted API key) — search-quality, safely-isolated memory, as a dependency, not a service.

Concretely, rmbr gives you:

• One file. Your agent's entire memory and knowledge base is a single .db file — git commit it, diff it, roll it back, hand it to a teammate, attach it to a bug report, or check a known-good state into a test fixture for deterministic CI. No hosted memory service lets you do any of that.
• Three lines. pip install rmbr, import, remember. No account, no config, no service.
• No added infrastructure. Your agent already needs a network connection and an API key for its LLM calls — rmbr doesn't add a *second* one just for memory. mem0 defaults to a hosted LLM+embedding API, Zep needs Docker+Neo4j+an LLM key, Letta needs a server+Postgres — all on top of whatever you're already paying for the model itself. rmbr's own memory/retrieval path makes zero network calls by default: one less vendor, one less key to leak, one less service whose outage takes your agent's memory down with it. (It also means rmbr keeps working with a fully local LLM — Ollama, llama.cpp — for genuinely offline or air-gapped use; most people won't need that, but it's there.)
• No proprietary format. rmbr never calls an LLM itself — recall()/search() return plain strings, floats, and dicts (hit.text, hit.score, hit.metadata). Nothing to parse, no vendor SDK required to consume it — see Using results with an LLM below for how that plugs into Claude, GPT, or Gemini identically.
• Namespace-pinned multi-agent access. Policy is deny-by-default; MCP tools expose no namespace parameter to override — safe by construction, not by convention.

Quickstart

from rmbr import Memory

mem = Memory("agents.db", namespace="assistant") mem.remember("user prefers dark mode and short answers") mem.recall("user preferences")

Three lines — that's the whole API for the common case. Everything below is opt-in and lives in its own section, so you only read what you actually need. Library-only by design — no CLI to learn. (python -m rmbr exists solely so MCP clients can launch the server; see MCP support below.)

`agents.db` doesn't need to exist first. There's no rmbr init, no template to download, nothing to provision — Memory(path, ...) (and Index(path)) create the file the moment you call them on a path that doesn't exist yet, with the right schema already in place. The one thing that does need to exist is the *directory* the path lives in (same as opening any file for writing) — Memory("agents.db", ...) works from wherever you run it; Memory("some/deep/agents.db", ...) needs some/ to already be there.

Indexing documents (RAG)

from rmbr import Index

idx = Index("agents.db") idx.add_files("docs/") # .py, .md, and plain text each get an appropriate splitter automatically hits = idx.search("how do I deploy?", k=5) hits[0].text, hits[0].score, hits.timings # per-stage latency, always visible

Index and Memory share the same .db file — open both against the same path if your agent needs a knowledge base *and* a memory. add_files()/add_texts() return an IngestResult: a plain list of document ids with a .timings breakdown attached (chunk_ms/embed_ms/store_ms/ann_ms/docs_per_second) — the same transparency hits.timings gives you for search, applied to ingestion, so you can see for yourself that embedding dominates the cost rather than take our word for it.

Using results with an LLM

rmbr never calls a model — search()/recall() hand you back plain text and a score, and you decide what to do with it. The standard pattern (classic RAG: retrieve, then inject the retrieved text into the prompt) with Claude:

from anthropic import Anthropic

from rmbr import Index

idx = Index("agents.db") idx.add_files("docs/")

client = Anthropic() # reads ANTHROPIC_API_KEY from the environment

def answer(question: str) -> str: hits = idx.search(question, k=5) context = "\n\n".join(f" {hit.text} " for hit in hits) response = client.messages.create( model="claude-sonnet-5", max_tokens=1024,

Context before the question, not after — Anthropic's own prompting

docs measure this ordering as meaningfully better for long-context

RAG, though it isn't required for correctness.

messages=[{"role": "user", "content": f"{context}\n\nUsing the documents above, answer: {question}"}], ) return response.content[0].text

answer("how do I deploy?")

This isn't Claude-specific. hit.text is a plain Python string with no wrapper, no provider object, nothing rmbr-proprietary — the exact same context string above drops verbatim into OpenAI's messages array (client.chat.completions.create(model=..., messages=[...])) or Gemini's contents. Every mainstream chat-completion API takes the same fundamental shape (a list of role-tagged text messages), which is why "retrieve text, put it in the prompt" — the only integration contract rmbr makes — works identically across providers. Swap the SDK call, nothing else changes.

Want the embedding itself to come from a hosted provider instead of the local default? Memory("agents.db", namespace="assistant", embedder=OpenAIEmbedder()) (pip install rmbr[openai]) — VoyageEmbedder/pip install rmbr[voyage] and CohereEmbedder/pip install rmbr[cohere] are also available, all three behind the exact same Embedder protocol, same rest of the API.

Keeping memory accurate over time

remember() inserting forever is fine for a while, then it isn't: near-duplicate notes pile up, and nothing ever expires. rmbr doesn't have an LLM to judge "is this the same fact" the way mem0's extraction loop does — everything below is deterministic vector-similarity/time-based engineering instead, opt-in because a false-positive match is a worse failure than a duplicate:

# Update-in-place instead of appending, above a cosine-similarity threshold.

Off by default — no LLM here to judge intent, so keep it conservative (0.92-0.95).

mem = Memory("agents.db", namespace="assistant", dedupe_threshold=0.93) mem.remember("user prefers dark mode") # inserts mem.remember("user really prefers dark mode") # updates the same row if similarity clears the bar

Bound growth automatically (evicts the oldest beyond the cap on every remember()),

or prune on your own schedule:

mem = Memory("agents.db", namespace="assistant", max_memories=5000) mem.forget_older_than(60 * 60 * 24 * 30) # delete anything older than 30 days

max_memories eviction is pure recency by default, which is a real risk once

you rely on it - a trivial fact from an hour ago would otherwise outlive a

critical one from last week for no reason but timestamp. Exempt specific

memories from it:

mem.remember("the customer's account was permanently deactivated", pinned=True)

Loading many items into an already-large namespace (an org's internal doc set, a backfill of historical memories) is a different situation than a single remember() mid-conversation — batch it:

# Without this, every single remember()/add_text() call re-serializes the

*entire* vector index (usearch has no incremental on-disk save) - fine

at hundreds-to-low-thousands per namespace, real cost once a namespace

has tens of thousands of items and you're adding