Show HN: Memobase – Universal memory that works across all your AI tools(memobase.ai)
memobase.ai
Show HN: Memobase – Universal memory that works across all your AI tools
https://memobase.ai/
20 comments
Building in the same space (Maximem Vity, cross-LLM memory as a Chrome extension and OpenClaw plugin). The SMTP analogy really resonates with me. I wrote a comparison a few weeks ago of how ChatGPT, Claude, and OpenClaw actually implement memory under the hood [1] and the architectures are so different that interop feels almost accidental when it works.
One thing I keep running into: the hard part isn't storage or retrieval. It's qualification. Deciding what's worth remembering from a conversation vs. what's throwaway context. ChatGPT takes the "summarize the last 15 chats" approach, Claude does on-demand search, and both have real failure modes. We went with a semantic graph that tries to capture relationships between memories (your preference for serverless connects to your AWS project connects to your cost constraints) rather than flat key-value pairs. Still iterating on it honestly.
Re: Claude's import-memory launch yesterday, I think the timing validates the category but the approach is fundamentally migration, not sync. You import once, and from that moment your contexts diverge again. Anyone using 3+ tools daily (which is basically everyone I talk to) is back to fragmented memory within a week.
Curious about your retrieval approach. Are you doing hybrid search or pure semantic?
[1] https://www.maximem.ai/blog/ai-apps-memory
Nice - good to see activity in this space, the more folks are on it the quicker we'll get to a world with a satisfactory solution.
I like your approach - I went down a bit more of a swiss-army-knife one with a hybrid.
"Session memory" where turns are stored in full so that the full context can be retrieved if an important fact is missed in compaction. After a certain time sessions are compacted. I'm currently evaluating a model where only a certain number of turns per session are kept plain-text and compaction happens as a sliding window "knowledge memory" All info is periodically fed into a knowledge graph extraction and a knowledge graph is built and indexed "memory chunking" chunks of memory are stored individually into a vector space where they can be retrieved through similarity search as well as standard semantic searches.
My theory is that giving the agent flexibiity to query the tool best suited for it's current needs is the way to go, as agents/llms become better, they'll only get better at summarisation and tool choice.
Couple reasons I like storing more data over less is that storage is cheap and if compaction misses details, you can prompt your agent to go back to that session you had about X last week and extract that detail.
Similar to you however, it's still also very early stages and the ground is shifting rapidly. Claude Codes HTTP hooks are a great step towards a model that I believe can work assuming it gets adopted as a standard. A big problem of having memory be portable is that you gotta be able to plug it into any client you want, and for the time being, MCP + system prompt is the only option - and even that one's more than flaky.
Would be awesome to chat to someone from OpenAI or Anthropic on their take and pow-wow on options
I like your approach - I went down a bit more of a swiss-army-knife one with a hybrid.
"Session memory" where turns are stored in full so that the full context can be retrieved if an important fact is missed in compaction. After a certain time sessions are compacted. I'm currently evaluating a model where only a certain number of turns per session are kept plain-text and compaction happens as a sliding window "knowledge memory" All info is periodically fed into a knowledge graph extraction and a knowledge graph is built and indexed "memory chunking" chunks of memory are stored individually into a vector space where they can be retrieved through similarity search as well as standard semantic searches.
My theory is that giving the agent flexibiity to query the tool best suited for it's current needs is the way to go, as agents/llms become better, they'll only get better at summarisation and tool choice.
Couple reasons I like storing more data over less is that storage is cheap and if compaction misses details, you can prompt your agent to go back to that session you had about X last week and extract that detail.
Similar to you however, it's still also very early stages and the ground is shifting rapidly. Claude Codes HTTP hooks are a great step towards a model that I believe can work assuming it gets adopted as a standard. A big problem of having memory be portable is that you gotta be able to plug it into any client you want, and for the time being, MCP + system prompt is the only option - and even that one's more than flaky.
Would be awesome to chat to someone from OpenAI or Anthropic on their take and pow-wow on options
Update from two days later: we shipped the Claude Code HTTP hooks integration.
The injection problem I mentioned earlier, of memory not loading automatically without system prompt config is now partially solved for Claude Code. SessionStart hook auto-injects memory capabilities, TaskCompleted tracks turns, SessionEnd persists everything.
It's also clarified our thinking on the protocol question: lifecycle hooks (SessionStart, SessionEnd, ContextCompaction) feel like the right abstraction for ambient memory. If other tools did the same, you'd configure memory once and it would work everywhere.
Any thoughts or feedback on the topic are welcome
The injection problem I mentioned earlier, of memory not loading automatically without system prompt config is now partially solved for Claude Code. SessionStart hook auto-injects memory capabilities, TaskCompleted tracks turns, SessionEnd persists everything.
It's also clarified our thinking on the protocol question: lifecycle hooks (SessionStart, SessionEnd, ContextCompaction) feel like the right abstraction for ambient memory. If other tools did the same, you'd configure memory once and it would work everywhere.
Any thoughts or feedback on the topic are welcome
Interesting positioning. Cross-tool memory portability is the right direction. A practical trust layer to add: every recalled item should carry provenance + freshness metadata so agents can choose whether to trust, refresh, or ignore memory instead of treating all recalls as equally valid.
Thanks - glad it resonates. Great idea on the freshness that makes total sense. I'll add that for sure
//Edit: I've implemented this and it's live now
//Edit: I've implemented this and it's live now
this is super cool. can i get it to work as effortlessly as a chrome plugin? I use a lot of different models and a lot of specific/vertical ai on different products that I'd love to not have to constantly give context to to be useful.
love where this is headed!
love where this is headed!
Short answer is yes - just add the MCP server and you're golden. Longer answer is that most chat clients do not allow the MCP server to automatically inject it's own system prompt which means you have to specifically prompt your AI to write to memobase.
jlongo78(1)
Timing: Anthropic just launched memory import for Claude yesterday. You can export your ChatGPT memories and bring them over. It's a step in the right direction, but it's still moving your data from one silo to another. You don't really own that memory.
The problem as I see it: there's no standard protocol for AI memory. You can't say "here's my MCP server, use it for memory in every session." Each platform builds its own walled garden. Number portability took regulation. Email interoperability took SMTP. AI memory needs something similar.
What Memobase is: a universal, AI-agnostic memory layer. It builds a structured profile — your preferences, context, project history — that any connected AI tool reads from. Not locked inside ChatGPT, Claude, or any single platform.
Technical approach: - Profile-based memory, not raw conversation logs. Compact and fast (sub-100ms lookups). - You own your data. Full visibility, editing, deletion, export. Self-hosted option coming. - Working toward an open protocol so any tool can plug in — not just our integrations.
What's live: open beta with the core memory and integrations for the major tools. What's still patchy: Agents don't automatically use it all the time without being prodded, the protocol spec is still being formalized, and we need more tools to adopt it for this to really work.
I'd love to hear: - Would you want your AI memory to live outside any single platform, or do you prefer each tool handling it? - What would the protocol need to look like for you to build against it? - Technical feedback on the approach — we chose profile-based RAG vs knowledge graphs etc, happy to go deep on that.