PMB - Stop re-explaining your project to AI coding agents

@tang_weigang Please do test it first - it's open source, so you can inspect the SQLite and confirm the read path makes zero network calls. And you've named the real problem: it's not storage, it's when a fact should lose authority. Today that's soft (recency + forgetting-curve decay) plus hard latest-wins for keyed facts, but there's no explicit per-item expiry or conflict flag for free-text decisions yet - so a REST decision after a GraphQL switch loses weight, but isn't hard-suppressed.

Both your ideas are spot on and going on the list: locality-scoped authority - injecting an old decision only if the current file still touches that path - maps directly onto PMB's code-entity graph (today it's emergent from ranking, not a hard gate); and the dashboard showing "skipped because it conflicted with newer evidence," not just "this memory helped," is the version that makes it auditable instead of trust-me.

Repo if you want to follow along: https://github.com/oleksiijko/pmb

@shubham4real Thanks - and you've got the reasoning exactly right: the read path is pure local retrieval, so context costs you milliseconds, not an API call per interaction.

On conflicts: partially. For facts with a clean key it's resolved - latest-wins, old value archived. For two free-text decisions that contradict on the same part of the codebase, it's honest-partial today: both are stored as events, recency decay and relevance ranking push the newer one up, but there's no semantic detection that says "these two conflict" and hard-suppresses the stale one - so worst case both stay retrievable until one is corrected or archived. The hook for fixing it is already there, though: decisions about the same code cluster on the same entities in the graph, so detecting a conflict on a shared entity and flagging it for supersede/review is the next build.

Repo if you want to follow along: https://github.com/oleksiijko/pmb

@farrukh_butt1 Thanks - shared across tools is the whole point: the memory follows you from Claude Code to Cursor to Codex, so you explain a decision once, not once per tool.
github.com/oleksiijko/pmb

@matthieu_poitrimolt That "least favorite part of the day" line is exactly why I built it. Quietly repeating yourself all day is the thing I wanted gone - thank you.

@borrellbr Thanks! A few things, shaped largely by the questions in this very thread:

• Memory lifecycle: first-class active / superseded / needs-review states for decisions, with auto-detection when a newer decision reverses an older one, so stale context loses authority instead of lingering.

• Conflict surfacing: a dashboard view showing not just "this memory helped" but "this was skipped because it conflicted with newer evidence," plus a per-session memory diff (what was added, updated, and what influenced a suggestion).

• Locality-scoped recall: lean harder on the code-entity graph so a decision only surfaces when the file you're touching still relates to it.

• A reproducible benchmark harness in the repo (with/without PMB, N runs, tokens + pass/fail + quality), so the speed and quality claims are verifiable, not trust-me.

On direction: PMB stays local-first and fully open source. I'm not planning paid features - if anything ever gets added behind a flag it'll only be by explicit request from people who need it, and the core stays free and open for everyone. The goal is a tool you own, not a funnel into a subscription.

Repo: https://github.com/oleksiijko/pmb

@sabber_ahamed Exactly. “Local-first” is not just a privacy feature here, it changes what users are willing to let the agent remember. For retrieval: it’s holding up well so far. My own PMB workspace is already at thousands of entities and tens of thousands of graph connections, and warm recall is still fast because SQLite stays the source of truth, while BM25 + vector search + graph expansion are used as retrieval/ranking layers. The biggest challenge has not been raw speed, but precision: making sure the agent gets the few memories that matter, not a huge context dump. So PMB is intentionally conservative about what it surfaces, especially for lessons/rules. HealthOS sounds like a perfect use case for the same constraint btw - health memory is exactly the kind of data people should not have to put in a cloud just to make it useful.

@mahir21 Yes, that’s exactly the idea, with one important nuance: PMB does not just dump the entire raw chat history into memory.

It stores the durable stuff that should survive between sessions: project decisions, lessons, bugs, goals, files touched, constraints, and “don’t do this again” rules.

So you can work in Claude Code, then later open Codex / Cursor / another MCP-aware agent connected to the same PMB workspace, and it can pick up the relevant context instead of starting from zero.

For plain ChatGPT, it depends on whether the client has a way to connect to PMB/MCP. But across MCP-compatible coding agents, yes - that is the workflow PMB is built for.

@ozandag That’s exactly the hard part: memory is only useful if it has scope and authority, not just storage.

PMB already does a few things here. Recall is not a flat keyword search: memories are ranked with multiple signals - lexical/vector match, importance, recency, graph/entity proximity, and follow-through history for lessons. The graph links decisions, lessons, files, projects, and entities, so a newer decision tied to a specific service/file can win in that context over a broader older rule.

So in your example, “never use ORM” would be treated as a general lesson. If later we store “use ORM for this billing service”, that newer and more specific decision should surface for billing-service work because of recency, entity scope, and graph relevance. The older lesson can still be useful elsewhere, but it should not have infinite authority.

The honest answer: PMB already has weighting, scoped recall, and conflict detection for factual state. The next step is making lifecycle explicit for decisions/lessons too - active / superseded / needs-review - and showing those conflicts in the dashboard instead of hiding them.

The goal is not “remember everything forever”. It’s memory with weight, scope, and aging.

@yannikga That is exactly the failure mode I care about too: stale memory is worse than no memory if you cannot see where it came from.

Today PMB already gives attribution for the lesson path. When a lesson is surfaced, it gets a surface_id; later agent actions can be linked back to that surface, and PMB tracks whether it was followed, ignored, or not applicable. The Earned Memory layer then connects surfaced lessons to outcomes like tests passing, builds, deploys, red-to-green fixes, and churn.

For clean factual state, PMB also has validity/supersession mechanics: newer keyed facts can supersede older ones while keeping history and provenance.

The honest answer on your exact “newer event reverses an older one without a clean key” case: today, you can inspect the events and attribution trail, but the dashboard does not yet give a universal “skipped because of X” explanation for every memory type. That is the direction I want to take it: explicit active / superseded / needs-review states, plus a dashboard view that shows why a memory was used, skipped, or considered stale.

I agree with your framing: context without provenance is noise. PMB should make memory accountable, not just persistent.

Repo is here if you want to take a look or follow the work: https://github.com/oleksiijko/pmb