Show HN: Memobase – Universal memory that works across all your AI tools (memobase.ai)
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.
6 comments
[ 2.8 ms ] story [ 28.6 ms ] threadlove where this is headed!
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
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