PMB - Stop re-explaining your project to AI coding agents
by•
PMB gives Claude Code, Cursor, Codex and Zed persistent project memory through MCP. It stores decisions, lessons, goals, recent work, project facts and docs in one SQLite workspace on your disk. No cloud, no API keys, no LLM call on the read path. It is open source, offline-first, inspectable/exportable, with a local dashboard and honest impact tracking so you can see which memories actually help.
Replies
PMB
@oleksiijko bless you - I needed this :) wishing you all the success!
PMB
@heather_dawn3 Thank you so much, this means a lot :)
That exact feeling - “I needed this” - is basically why I kept building it. Really appreciate the support.
Foyer
The core problem is real. Every new context window means re-explaining architecture decisions, naming conventions, the reason you made that weird choice in the auth layer three months ago. Curious whether PMB is basically a structured prompt file that lives in the repo, or whether there's something more dynamic happening, like the context getting selectively injected based on what part of the codebase the agent is touching. Also wondering how you handle drift, because the project memory that was accurate at week two is often wrong or incomplete by month six, and a stale context file might be worse than no context file.
PMB
@fberrez1 Great questions - you're pointing at the two things that actually matter here.
On architecture: it's the dynamic side, not a prompt file in the repo. PMB is a real store (SQLite) of events, decisions, lessons, facts and a code-entity graph. On each task the agent calls prepare() / recall() over MCP, and a hybrid retriever (BM25 + vectors + entity graph, fused) pulls back only the context relevant to what it's touching, ranked by relevance and recency - not a flat dump. Writes are ambient too: decisions and lessons get captured as you work, not hand-maintained.
On drift - this is the part I think about most, and I agree a stale context file can be worse than none. A few mechanisms:
Recency + forgetting-curve decay, so week-two context loses weight over time instead of competing head-on with fresh context.
Corrections override: when you correct the agent, that's stored as a high-priority lesson that outranks what it contradicts.
Keyed facts (attribute = value) are latest-wins with the old value archived, so a changed fact is genuinely superseded, not left lying around.
Dedup merges near-identical entries, so "we decided X" isn't stored five times.
Where it's headed: a first-class lifecycle for free-form decisions/lessons - explicit active / superseded / needs-review states, and auto-detecting when a new decision reverses an older one. That's clean for keyed facts today, less so for free-text decisions, and it's the next thing on the list.
If you want to follow where it goes, here's the repo: https://github.com/oleksiijko/pmb
ModuleX
The local SQLite memory feels like the right call for keeping project context off the cloud, but I'm curious what stops an old decision you reversed two sessions ago from still surfacing as if it's current when the agent reads back?
PMB
@sezerufukyavuz That’s exactly the failure mode PMB is designed to avoid. Memory should not be treated as “true forever.”
PMB ranks recall by relevance, recency, importance, graph/entity proximity, and file/service scope, so a newer, more specific decision should outrank an older generic one. For state-like facts, PMB also has supersession/validity mechanics: the old value is kept as history, but no longer treated as current.
The next step is making this even more visible in the dashboard with explicit active / superseded / needs-review states for decisions and lessons.
The re-explaining problem is genuinely painful. Every new Claude Code session starts with several minutes catching it up on decisions already made, directions already tried, and why the architecture looks the way it does. Having MCP-backed persistent context that retains all of that locally - no cloud, no API overhead on reads - is the right shape for this problem. The SQLite approach is smart for anything touching sensitive project details. Curious: how does it handle conflicts if two different agents write to memory simultaneously on the same project?
PMB
@galdayan Thanks Gal - and you nailed the shape of the problem. On concurrent writes, same machine / same project it's safe by construction:
The store is append-only - every write is a new event with its own ULID, not an in-place edit of a shared row. Two agents writing at once just append two events; neither clobbers the other, so there are no lost updates.
Under the hood SQLite runs in WAL mode with a 10s busy-timeout (set automatically), so a second writer waits and serializes instead of erroring or corrupting.
The 4-layer dedup then merges near-identical entries after the fact, so you don't end up with "we decided X" stored twice. For keyed facts (attribute = value) it's latest-wins with the old value archived, not overwritten.
The only place real merge conflicts can show up is cross-machine git-sync of a workspace - that's plain git + a WAL checkpoint before commit. On one box, two agents on one project just coexist.
PMB
Why I built this: every new Claude Code / Cursor session I'd burn the first 10 minutes re-explaining the same things - which decisions we'd already made, which directions we'd tried and ruled out, why the architecture looks the way it does. The agent forgets all of it between sessions, after every model upgrade, every time I switch tools. Teaching it the same lesson for the fifth time ("we use pnpm, never npm") was the most demoralizing part of working with an AI agent.
So I made the memory live locally - one SQLite file over MCP - and fed it back automatically before the model thinks, instead of hoping it remembers to look. Now it shows up already knowing. No cloud, no API keys, and I can open the dashboard and see exactly what it remembers. That's the whole pitch.
memory is the half of agent workflows nobody talks about. every demo shows the magical "it just knew" moment but never how it knew. once you ship multiple agents working in the same codebase, memory is the only thing keeping their fights from becoming bugs.
the part still missing across the space is provenance. memory says "these are the decisions." but who made each one, when, based on what context? without that you eventually get the agent equivalent of "why is this code here? git blame says steve from 2019."
local plus sqlite is the right call. ship it.
PMB
@thenameisarian This nails it - and provenance is exactly the right frontier. PMB already stamps every event with who wrote it (actor/source), when, and which session it came from, so "git blame for decisions" exists at the who/when level. The harder piece - tying each decision to the context that produced it - is what I'm building toward. And the multi-agent "fights becoming bugs" line is painfully accurate.
Appreciate the ship-it. Repo if you want to follow along: https://github.com/oleksiijko/pmb
The re-explaining loop between sessions is exactly what drives me nuts with Cursor and Claude Code, so local SQLite memory over MCP feels like the right call. How are you deciding what gets stored automatically vs what I have to tell it to remember? congrats on shipping.
PMB
@i_sanjay_gautam Thanks! And that loop is exactly what set me off too.
The split is roughly this: an ambient layer captures the work product automatically - decisions, lessons, corrections (when you correct the agent, that's stored as a high-priority lesson), and completed work - with dedup so the same thing isn't stored twice and secrets redacted on write. You don't have to narrate any of it. Explicit "remember this" is the override: things you want pinned, personal facts, or future intent the agent wouldn't infer from the work itself. Default is you shouldn't have to tell it - telling it is for emphasis or for what falls outside the work stream.
Repo if you want to follow along: https://github.com/oleksiijko/pmb
Curious how PMB handles context boundaries in practice — is it meant to store high-level project docs, repo-specific conventions, current tasks, or some mix of those?
PMB
@crystalmei It's intentionally a mix of all of those - the design goal is that you don't have to pre-sort it.
In practice: repo-specific conventions land as lessons ("we use X, never Y"), architectural direction as decisions, current work as goals/activity, and higher-level docs as reference/facts (it can ingest docs and PDFs too). Boundaries between projects are hard: each repo is its own workspace with a separate store, so conventions from one project can't bleed into another. Within a project, retrieval pulls the relevant blend for the task at hand - a convention plus a current goal plus the related decision - rather than dumping everything. So the boundary isn't something you draw by hand; workspaces wall off per repo, and relevance picks the slice per task.
Repo if you want to follow along: https://github.com/oleksiijko/pmb
Local-first append-only is the right base. The thing that actually bit us running a file-based memory like this for our own agents was staleness: the agent confidently acted on a decision that had been reversed two sessions back, because the old event was still sitting on the read path. Append-only sharpens that, since both the decision and its reversal live as events. Does the read path collapse to current state, or can the agent pull a superseded decision and treat it as live?
PMB
@dipankar_sarkar You've described the exact failure mode, and you're right that append-only sharpens it: the decision and its reversal both live as events, so the read path has to decide which one is "true."
Honest answer, split by type:
Keyed facts (attribute = value): the read path collapses to current state. Latest-wins, the prior value is archived off the read path - the agent gets the live value, not the superseded one.
Explicit corrections: when a reversal comes in as a correction, it's stored high-priority and outranks what it contradicts.
Free-text decisions/lessons: this is the gap. Today there's no semantic reversal-detection, so both events stay retrievable. Recency + forgetting-curve decay ranks the newer (reversal) event above the old one, so in practice the fresh one usually surfaces - but you're right that a superseded free-text decision can still be pulled and treated as live in the worst case. I won't pretend that's fully solved.
That's exactly what I'm building next: a first-class lifecycle (active / superseded / needs-review) with auto reversal-detection, so the read path collapses free-text decisions to current state the way keyed facts already do - with the superseded event available only on an explicit history/time-travel query, not the default read path.
Appreciate you raising the precise version of this - it's the right thing to be hard on.
Repo if you want to follow where it goes: https://github.com/oleksiijko/pmb
PMB
@divvsaxena Fair hit - the video's weak and I know it. Redoing it properly is on the list. Appreciate the honesty, and the upvote anyway :)