MemoryCustodian

Is there a review step before something becomes durable, or does it persist the moment the agent decides it's worth keeping?

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?

the deleted like code phrasing is doing more work than it looks. deleting a memory file takes it out of the working tree, but if it was ever committed it stays in history, in every clone, and in every fork. so forgetting is reversible for anyone holding the repo.matters because rejected-approach notes are exactly where the sensitive material collects. we cannot use X because of the contract with Y, or this is throttled because vendor Z caps us at N. fine in a private repo among employees, less fine once a contractor clones it or the project goes open source.not an argument against repo-native, I still think the tradeoff lands your way. just that safe forgetting probably wants a line in the docs about what it does and does not cover...

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.

Repo-native is the right call, and the branch question above is the obvious follow-up — so I'll ask the one underneath it. What happens when the project isn't one repo?Mine is three: the app, the infrastructure, and the marketing site. The decisions that bite me are almost always made in one and violated in another — a constraint I set while working on infra that the agent working in the app repo has never seen. Repo-native is exactly right for "why is this code shaped this way." It also makes the repo the trust boundary, and my project boundary is wider than that.Is sharing a memory module across repos something you'd support — a submodule, a symlink, a shared manifest entry — or is one-repo-one-memory a deliberate scope call?

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.

Different failure mode than the branch/rebase question above: two agent sessions on separate branches each append a note to constraints.md, no line-level conflict so git merges both cleanly, but the notes contradict each other (one says 'never use library X', the other says 'X is now required for Y'). Nothing breaks at merge time, the file just quietly holds two decisions that can't both be true. Is there any detection for that, or does it rely on someone eventually reading the file top to bottom and noticing?

Memory is key for agents! Glad to see you helping on this Zekun! Wish you all the best

Repo-native is the right instinct — memory that lives outside the repo drifts away from the code it describes almost immediately, and then you're maintaining two sources of truth about the same system.The question that follows is what happens on a branch. If memory is committed alongside code, then a note written on a feature branch is invisible on main until merge, which is arguably correct but might surprise people. And a rebase or a squash would rewrite the memory's history along with everything else. Is memory versioned with the code by design, or does it sit in the repo but outside normal git flow?

Plain Markdown in the repo instead of a hosted service is the right call for me. My worry is upkeep, and I saw you support correcting and forgetting memory, so the tooling is there. It is the habit I am unsure about. The file is only worth anything as long as someone keeps it honest, and when you work alone that someone is you. Not a criticism of the approach, I think the approach is sound. Nice launch!

the "manifest loads only the memory relevant to each task" line is the part I'd poke at. relevance selection is its own hard problem - if it's simple keyword or path matching against the task description that's predictable, but if the agent itself is judging which memory files matter for the current task, you can end up with the same failure mode you're trying to avoid: it just won't load the one constraint file it doesn't realize is relevant, and you get no error, just quietly wrong behavior. how does the manifest decide relevance today, and is there any way to see what got left out for a given task

Hey Product Hunt 👋I built MemoryCustodian because coding agents are increasingly capable, but every new session still tends to forget why a project looks the way it does.Important decisions, constraints, rejected approaches, and repeated corrections often live only in old conversations—or get copied into increasingly large instruction files.MemoryCustodian takes a different approach: durable project memory lives as plain Markdown inside the repository.A small manifest tells the agent which memory files are relevant to the current task, so the memory can grow without forcing every session to load the entire project history.What makes it different:Repo-native and plain text—no opaque memory databaseReviewable, versioned, and shareable through normal Git workflowsSelective loading instead of injecting all memory into every promptExplicit support for updating, correcting, and safely forgetting memoryWorks with Codex, Claude Code, Gemini, and generic coding-agent workflowsFree, open source, and local-firstThe repository also includes a reproducible NightNotes demo showing a new agent session recovering an existing architectural decision and avoiding an already-rejected implementation path.I’d especially love feedback on the memory structure, cross-agent workflow, and whether the installation experience feels simple enough for real projects.Thanks for checking it out!