MemoryCustodian
Repo-native memory for coding agents
194 followers
Repo-native memory for coding agents
194 followers
MemoryCustodian gives Codex, Claude Code, Gemini, and other coding agents durable project memory—without a hosted service or bloating every prompt. Decisions, constraints, rejected approaches, and project context live as plain Markdown in your repo, where they can be reviewed, versioned, shared, and deleted like code. A manifest loads only the memory relevant to each task. Open source, local-first, and cross-agent.
Congrats on the launch. Recording rejected approaches is the part most memory systems skip entirely, and it might be the highest value item on your list, because without it an agent will cheerfully re-propose the thing you already ruled out last month.
The manifest is the interesting design call. How do you handle relevance drifting, where a file was genuinely relevant when written but is not for the task at hand, and the agent cannot tell the difference until it has already loaded it?
Plain Markdown in the repo is the right default either way, since it means a human can actually audit what the agent believes about the project.
MemoryCustodian
@paul_crinigan Thank you! and agreed on rejected approaches. Preventing an agent from rediscovering the same dead end is one of the main reasons this exists.
The manifest handles routing relevance, not whether every entry inside a routed file is still current. Today, keeping files short and scoping subsystem knowledge into separate area files makes drift easier to notice, but it does not eliminate it.
The direction in the plan is to make that drift visible through explicit supersession, evidence freshness checks, and explanations of why each module was loaded or skipped, not to silently assume that newer memory is correct.
Love the repo native approach. How do you handle memory that is stale or contradicts another note? Does the agent get warned before it trusts that context, or does someone have to catch it during review?
MemoryCustodian
@flavio_riper Good question. Today, this is partly handled by process rather than a general semantic conflict detector.
The agent is instructed to update, merge, or explicitly supersede an existing entry instead of appending a contradictory one, and memory audits compare durable claims against the current code and authoritative project files.
But the honest answer is that MemoryCustodian cannot yet guarantee a warning before every stale or differently worded contradiction is trusted. Structural issues can be checked deterministically; semantic drift still needs to be caught by the agent or during review. The direction is to make that risk more visible through explicit supersession, provenance, freshness, and conflict auditing—not to assume that the newest note automatically wins.
MemoryCustodian
@etiennegarcia Thank you! I think that is the real tradeoff.
Plain Markdown makes memory inspectable, but it does not make maintenance disappear. The intended habit is event-driven rather than periodic: after a meaningful decision, repeated correction, or rejected approach, the agent should propose a small memory update while the context is still fresh.
A solo maintainer is still the final curator. I would rather keep that responsibility visible and reviewable than hide it behind an automatic memory system that quietly accumulates incorrect beliefs.
Is there a review step before something becomes durable, or does it persist the moment the agent decides it's worth keeping?
MemoryCustodian
@tmaleh_ There isn’t a separate MemoryCustodian approval gate today. A confirmed entry can become active in the current checkout when the agent writes it.
Because the memory is stored in the repo, that change is already part of the same diff and PR as the code it accompanies, so it gets reviewed through the normal development workflow. If the scope or confidence is unclear, the agent should propose the update or leave it in the inbox rather than promote it directly.
MonoCloud for Startups
Plain Markdown in the repo means agent memory goes through code review like everything else, which is the whole reason teams will adopt it. I run two developer-facing products and the pattern repeats, nobody trusts memory they cannot audit. A hosted memory service is one more vendor in the compliance review, a Markdown file ships with the PR. And the manifest that loads only task-relevant memory deserves top billing, context bloat is what kills long-running agents.
MemoryCustodian
@roguetink Thank you! This is exactly the tradeoff we were designing around.
Memory should be reviewable like code, not hidden behind another opaque service. And keeping the memory store durable only works if the context loaded for each task stays bounded.
Really appreciate you calling out both sides of the design!
Memory is key for agents! Glad to see you helping on this Zekun! Wish you all the best
MemoryCustodian
@german_merlo1 Thank you so much! Really appreciate the support. It means a lot.