Memmy Agent - Let every AI remember the same you.
🍙 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.
Replies
Does commercial use of the GitHub version have any licensing restrictions that companies should know about?
@sky_heartfly Memmy is MIT-licensed, so yes, commercial use is allowed. You’re free to use, modify, and distribute it, as long as you keep the original copyright and license notice. No extra commercial restrictions from us.
@sky_heartflyMemmy is MIT-licensed, so yes, commercial use is allowed. You’re free to use, modify, and distribute it, as long as you keep the original copyright and license notice. No extra commercial restrictions from us. As usual with open source, third-party dependencies keep their own licenses — worth a quick check if your company has a compliance process. Happy to clarify further!
@sky_heartfly The MIT answer you got is correct, and there is a second question underneath yours that matters more for a company.
MIT covers the code. It says nothing about where your data goes. For a memory layer that is the part legal will actually ask about, because the whole product is a store of everything your team has said to its tools. Self-hosted from the repo and the hosted version with free tokens are very different answers to that question, even though both sit under the same licence.
The other thing the makers flagged themselves: third-party dependencies keep their own licences. That is the bit that trips people up. A permissive top-level licence with a copyleft dependency buried three levels down is a real situation, and it only surfaces during diligence when it is expensive.
If your company has any review process, running a dependency licence scan on the repo takes minutes and answers the question properly rather than by assumption.
@sky_heartfly @rabnoor_s Great add — you’re right that MIT answers the code question, not the data question.
For the GitHub / self-hosted path: memory stays local by default (SQLite on the machine). Scanning and ingestion don’t upload your memory store. If you use account-mode free tokens, model calls still go through the model provider like any BYOK/API setup — that’s separate from where the memory database lives. There’s also an optional memory-improvement toggle in privacy settings; it’s off unless you turn it on.
And yes on dependencies: a license scan on the repo is the right company diligence step. Appreciate you spelling that out for folks reading this thread.
@sky_heartfly Quick add: the top-level GitHub license is MIT, so commercial use is fine as long as you keep the copyright and license notice. Third-party dependencies still keep their own licenses, so a dependency scan is the safe move for company diligence.
If your team wants a cleaner commercial path — deployment help, compliance questions, or working directly with us as the vendor — happy to talk. Ping us anytime.
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.
@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.
@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.
congrats! @brattyaiguy
@brattyaiguy @danielwayne thanks bro 👊
@brattyaiguy @danielwayne Thanks~~~~
Quick video on how Memmy works
https://youtu.be/QURd0wkf4gI?si=cOLHwrsSlWWi5wXn
@brattyaiguy ♥️Go
Congrats on the launch! We're building humalike.ai and personal memory is one thing we care about :))
@mcarmonas Thanks Martí — just had a look at Humalike. The turn-taking and social memory angle is really interesting.
We’re approaching memory from the cross-agent side, so there’s probably a lot for us to compare notes on — especially around Hermes :)
@mcarmonas Thanks so much! Personal memory is right at the heart of what we’re building too — love that humalike.ai cares about the same thing. Would be great to exchange notes sometime :))
@mcarmonas Thanks! Love meeting folks building in the memory space — humalike ai looks fun 👀
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?
@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.
@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 🔐
I think I saw a similar service just a few days ago... Do you have a B2B offering? For example, so other AI services could integrate with your platform and get more information about their users?
@natalia_iankovych Yeah — other AI products can plug into Memmy through the API or CLI. The important part for us is that the user stays in control, rather than apps quietly building another profile behind the scenes.
The fuller B2B stack is more on the MemOS side, though the hosted version isn’t broadly available overseas yet. Curious what kind of product you’d want to plug it into — and would love your upvote if the direction clicks 🙌
Congrats on the launch guys!
AI remembering about me is very important in case I need to switch computers or generate a cartoon meme of myself based on what AI knows about me :) - this used to be trendy on social media
P.S:
I have made a livedemo for you, feel free to check it out
https://app.livedemo.ai/livedemos/6a6afd7fcc86a442a8fd9dd4
@gapostolov this is such a lovely surprise — thank you so much! 🙌
Really appreciate you taking the time to make a live demo for us. That honestly means a lot, especially on launch day. We’ll definitely check it out!
@gapostolov Thanks so much! Glad this resonates with you — that’s exactly what Memmy is built for: keeping your context with you across devices and tools, so every AI remembers the same you.
Appreciate you making the livedemo too, just checked it out — really cool. Thanks for the support!
@gapostolov Thanks bro!!!!👊
I constantly bounce between different AI tools and having to re-explain project context every single time is a massive pain. The fact that Memmy turns that messy chat history into structured memory is exactly what my workflow needs.
@aren_barseghyan Thanks so much! That’s exactly the pain Memmy is built for — so you don’t have to re-explain your project every time you switch tools. Glad it fits your workflow. Thanks for the support!
@aren_barseghyan Same here. that constant context reset was driving us nuts toooooo... What tools are you bouncing between most these days? Curious where the handoff gets the messiest.
Shared memory across agents sounds powerful, especially with per-tool control. Can I create separate memory spaces for work, personal projects, and clients—and decide exactly which agent can access each one?
@blink_66 Not yet. Right now, all connected agents share one memory pool.
Separate memory spaces and per-agent access control are on our roadmap though — especially for people juggling work, personal, etc.
For now, separate Memmy instances are the cleanest workaround.
@yunn_chen Got it, thanks for clarifying!
@yunn_chen Separate Memmy instances sound like a practical workaround for now. I’m glad granular memory spaces and per-agent access controls are on the roadmap—those would make managing client and personal data much safer and more flexible. Looking forward to it!
@blink_66 yeaaah, shared memory is useful, but once client data is involved, the boundaries need to be much more explicit. Granular spaces and per-agent access controls are definitely an important next step for us. Thanks for the thoughtful feedback — really appreciate it.
@yunn_chen @blink_66 Appreciate you looping back — use cases like yours are exactly why isolation is high on the list. We’ll keep shipping toward that 🙌