oleksiibond

Repo for anyone who wants to look under the hood: https://github.com/oleksiijko/pmb

Proper Framing - AGENTS.md is fixed and always contextual irrespective of its relevance; memory is the exact opposite of it. PMB does not dump the store in, rather extracts only a small top-k relevant chunk per task (a few hundred tokens generally), hence, more storage in the form of facts does not necessarily translate to more context. "Useless facts" are precisely what it is grading against, i.e., items which do not serve any purpose will simply be considered dead and decayed.

It is a legitimate worry, but I would make it two separate questions since bloating and poisoning have their own solutions.

Bloating: PMB does not inject anything into the store, just gets a small top-k relevant snippet for every task - normally a few hundred tokens, not an increasing dump from the store.

Poisoning is the one that is more interesting and your example with reconstruction proves the point that PMB does not have LLM on its read side. Human memory - and indeed any mechanism that uses paraphrasing while recalling information via the model - reconstructs the information on its own each time, and that's what makes it susceptible to manipulation and hallucination.

That which cannot be accomplished is to correct garbage in, where a lesson wrongly learned is faithfully recalled. Mitigations include the fact that everything is verbatim, source-stamped (by who, when, session), de-duped, recently decayed, and correctable, and all of which is displayed on a dashboard – making an error of recall detectable and auditable, rather than silently reconstructive drift. Detection of conflict/supersession is the next build.

Agreed, and point number two is the tricky one. Creating a list of tasks is easy; evaluating them is not. You need a consistent task set, a "clean slate" control (i.e., Claude code without memory is your proper control) and an evaluation criteria which differentiates "uses fewer tokens" from "produces better results," otherwise you end up with vendors evaluating their own work.

Currently constructing a repeatable test harness for PMB: Fixed task, with/without memory, repeated N times, giving number of tokens/turns/passed/not passed with a subjective quality score too. Would be happy to share the task set and evaluation criteria for testing on anyone else's memory server or clean slate control, not just mine.

Fair enough, you are correct that both can be self-hosted, and thus "local" by itself is not the moat. And I do not want to make claims about being able to beat them in recall, since I have no benchmark to compare against, and I believe the temporal graph of Zep is powerful.

Two things that do make it different from their solutions:

1. An adaptive per-project lexicon that is created from your own memories and adjusts the weighting to give more relevance to your project's lexicon. It focuses on one codebase only. I have never seen that in both.

2. Memories are rule-aware: "lesson" is a first-class citizen, and the retrieval process tries to show the rule rather than the event where it was applied and whether the rule was followed.

Thus, the advantage is in project specialization and rule awareness.

But if what you need is a hosted, managed memory API, which you can plug into your own app, both Mem0 and Zep have great offerings and are more developed along those lines:

- Not local but hosted, meaning the memory will be stored remotely on their servers via an API. - Not directly integrated with your codebase but with the agent itself, which means that memory is automatically injected and captured within Claude Code, Cursor or Codex without any custom code of your own. Their offerings are SDKs which you have to integrate yourself. - Tool agnostic, since it uses MCP, meaning that memory is not tied to one specific app.

Summary: if privacy and "works in my existing agent with no code" is what you care about, go for PMB. If you need a hosted service for your own product, go for theirs.

Loops - Two.

Write: while working, PMB stores facts, decision, and learnings on MCP (automatically using hooks). Everything is saved to SQLite, gets embedded, and the entities get linked to a graph.

Read: before answering the prompt, a hook does a search (BM25 + embedding + entities graph using RRF) and provides the best matches. No manual recall required.

All on-premises: SQLite + LanceDB, embedder on-premises, and optionally Ollama.