You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I do not want to overclaim that this "solves memory." I am mostly curious whether this architecture feels useful, overbuilt, or missing something important.
If anyone has thoughts, I would especially appreciate critique on:
Does the memory-server / host-LLM boundary make sense?
Is graph-backed memory a useful abstraction here, or should this remain simpler?
What evaluation would best show whether this improves accuracy in real daily LLM workflows?
What failure modes should I test before claiming this direction is useful?
Thanks for reading. I would genuinely value technical pushback.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I built an open-source MCP memory server called Dense-Mem:
https://github.com/markhuangai/dense-mem
The idea I am trying to explore is that RAG is very useful for retrieval, but durable AI memory may need more than vector search alone.
In daily LLM workflows, the hard problems are often not just "find a similar chunk." They are questions like:
So Dense-Mem separates the host LLM from the memory layer:
I wrote more about the motivation here:
https://markhuang.ai/blog/ai-memory-beyond-rag
And I made a hosted demo so people can try it without self-hosting:
https://markhuang.ai/blog/dense-mem-hosted-demo-test-instance
I do not want to overclaim that this "solves memory." I am mostly curious whether this architecture feels useful, overbuilt, or missing something important.
If anyone has thoughts, I would especially appreciate critique on:
Thanks for reading. I would genuinely value technical pushback.
All reactions