
Memmy Agent
Let every AI remember the same you.
1.1K followers
Let every AI remember the same you.
1.1K followers
🍙 Memmy Agent is a personal memory hub and local AI agent for all AI Agent and tools like Claude Code, Codex, OpenClaw and Hermes. Gives every AI one shared, full-controlled memory — they all remember the same you. Memmy turns chats, decisions, prefs, progresses, and experiences into long-term memory, brings the right context into matching task, also can take on work directly. Local-first by default. Your memory stay under your control: manage them anytime. Free start with 2M ChatGPT tokens.










Retrieval analytics showing which memories helped, were ignored, or caused corrections could improve both user control and system quality.
Memmy Agent
@wys1010 Totally agree👍 That kind of retrieval analytics is a big unlock for both trust and quality. We already expose some of this in Memory Logs (candidates, what got filtered / dropped, what was actually injected), and we’re keen to push further toward clearer “helped / ignored / corrected” signals so users can steer the system and we can keep improving recall. Great call.
Memmy Agent
@wys1010 Thanks! Totally with you — being able to see how memories get used (or skipped) is a big part of making the system feel trustworthy 👍
Memmy Agent
Retrieval analytics could make memory much more observable and trustworthy.
Showing which memories were used, ignored, contradicted, or later corrected would give users a clear way to audit what influenced an answer. It would also help the system identify stale, low-value, or conflict-prone memories and improve retrieval over time.
The key is to present it as an understandable “memory trace,” with privacy-preserving local analytics by default—not an opaque scoring system.
I work across several products on one machine and a couple of them handle clinical data, so my question is about isolation: can memory be hard-scoped per project, or is separation just an outcome of retrieval ranking?
Memmy Agent
@soysebalopez Straight answer: today it’s the latter.
A Memmy instance uses one shared local memory pool. We do retain project, workspace, and source metadata, but that metadata isn’t enforced as a hard access boundary yet.
So for anything involving clinical data, I wouldn’t rely on retrieval ranking to keep projects separate. The practical setup today is to use separate Memmy instances and data stores, then validate that deployment against your own security requirements.
local-first, yes. Hard per-project isolation, not yet.
Memmy Agent
@soysebalopez Just to second that — today it’s ranking, not hard project sandboxes. For clinical data, a separate Memmy instance is the safer move until real isolation lands 🔐
Interesting thought: could a team use Memmy to help onboard new hires? There’s so much useful context that never makes it into the official docs.
Memmy Agent
@jody_l_wyatt That’s a great use case — and yes, team onboarding is already on our roadmap. So much of the real “how we actually work” never makes it into official docs; we’d love Memmy to help capture that tribal knowledge and make it usable for new hires. Appreciate you calling this out!
Memmy Agent
@jody_l_wyatt Love this — official docs never capture how work actually gets done. Memmy’s a natural fit for that tribal knowledge during onboarding 🙌
Oh this would be life-changing! I am curious, though, does this help Claude Code, etc., identify the right pieces of memory? Often, I've noticed that these AI models latch onto some obscure instance in the past and make decisions based on it. How do you ensure the memory being accessed is always relevant?
Memmy Agent
@thediffidentgarlicbread Great question. Memmy doesn’t dump the whole store into Claude Code. On each request it runs parallel retrieval, then relevance thresholds, dedup, MMR, and a final filter — only the most relevant snippets get injected. You can also check Memory Logs to see what was considered, dropped, and actually injected.
Memmy Agent
@thediffidentgarlicbread Once the Claude Code hook is on, recall and capture happen automatically. If you’ve got better ideas or real “it latched onto the wrong memory” cases, ping us anytime — happy to explore better fixes together 🙌
Congrats on the launch. Local-first is why I clicked, most memory layers ship as someone else's cloud. One thing I could not work out from the description: when Cursor and Claude Code both hit the OpenAI-compatible API, does a memory carry any scope with it, per project or per tool, or does every connected agent read from the same pool? I have work repos and personal side projects on the same machine and I would want the second not to bleed into the first.
Memmy Agent
@vollos Thanks for raising this — today, all connected agents read from the same local memory pool. That shared pool is intentional: it’s what allows Cursor, Claude Code, and other agents to build on the same long-term context.
At the moment, memories are not hard-isolated by tool or project. Retrieval is based on the current task and context, but a work repo and a personal side project still belong to the same pool, so we can’t promise zero crossover today.
If strict separation is required, the safest current setup is to use separate Memmy instances or data stores. Your example is a very useful one, and project-level boundaries are clearly an important requirement for this kind of workflow.
@yunn_chen Appreciate you saying that plainly instead of pointing me at a settings page, that is rarer than it should be. Separate instances sounds like the practical answer for now. Out of curiosity, do memories get tagged with where they came from at capture time? A pool that was never tagged seems hard to split later, so I wondered if that groundwork is already in there.
Memmy Agent
@vollos yeah,we do retain provenance at capture time. Memories can carry the originating agent/app, session and conversation, plus project and profile identifiers where available. So the shared pool isn’t an untagged blob.
that metadata is mainly used for tracing, inspection, and contextual retrieval; it isn’t yet enforced as a hard access boundary between projects. So separate instances are still the safest option for strict isolation, but the groundwork for future project- or tool-level scoping is already there.
@yunn_chen Clear, thanks. The split between what that metadata does today and what it could enforce later is the part I was guessing at.
the write-back is the interesting half. dedup handles the same fact twice, but the thing that actually bites is a memory that still sounds confidently true and just is not true anymore, and nothing in the chat history tells you which one that is
Memmy Agent
@alex_watson2110 yeah, stale-but-confident memory is the much harder problem.
When Memmy catches an explicit correction, it can create a decision-repair record and update the guidance built from that memory, rather than just storing two conflicting versions side by side. We still keep the original trace for provenance.
The part we’re improving now is making those conflicts easier to spot and review, instead of resolving everything silently in the background.
Memmy Agent
@alex_watson2110 Spot on — stale-but-confident memory is way scarier than simple dupes. The hard part is making corrections reviewable, not silently stacking conflicts 👍
@graceren the trap with making them reviewable is review fatigue. if every superseded fact becomes an item, people rubber-stamp the queue and you are back to silent resolution with extra steps.
since Pema mentioned you already keep decision-repair records, you can bound it with that: only surface a correction when the old belief actually fed a decision. nothing downstream, supersede it quietly. something downstream, that is the one a human should see, and you can show them exactly what it changes rather than just flagging a conflict.
Memmy Agent
@graceren @alex_watson2110 That’s a much better threshold than “review every conflict.” The thing worth surfacing isn’t just that a fact changed — it’s that the old fact actually influenced something downstream.
We already keep the two pieces needed for that: decision-repair records, and provenance for which memories were injected into a turn. What we don’t have yet is the user-facing impact view you’re describing.
Quietly supersede unused beliefs; surface the ones with downstream consequences; show exactly what would change. That’s a much cleaner contract.
Would love you to try the current flow and keep poking at it — and an upvote would mean a lot if the direction resonates.
Memmy Agent
@hannesh
Thanks! Yes.
Once Claude Code and Codex both have the Memmy hooks installed, they read and write the same local memory store. When a turn finishes on one side, it gets captured automatically; the next time you ask something on the other side, relevant memory can be recalled. It’s not separate silos per agent, and it’s not cloud push between them.
The key is that both sides need Memmy’s live integration. If you only scan history and don’t install the hooks, new conversations won’t share automatically.
Memmy Agent
@hannesh Anytime — feel free to ping if anything else comes up~