Mnexium AI
Persistent, structured memory for AI Agents
106 followers
Persistent, structured memory for AI Agents
106 followers
๐ง ๐๐ง๐๐ฑ๐ข๐ฎ๐ฆ = persistent memory for LLM apps. Add one ๐ฆ๐ง๐ฑ object and get chat history, semantic recall, and user profiles that follow users across sessions and providers. ๐ Works with ๐๐ก๐๐ญ๐๐๐ and ๐๐ฅ๐๐ฎ๐๐ โ same memories, any model. Switch mid-conversation without losing context. โ๏ธ No vector DBs or pipelines. A/B test, fail over, and route by cost โ your memory layer stays consistent.
Mnexium AI
@marius_ndiniย Cool idea touching on the primary limitation of the current LLMs. I see your algorithm curates what is memorized and at what importance. How are you feeding this back into a new chat with one of the LLMs, and does it eat up some of the context window? Or is this another mechanism that is presented to the LLM as an ability?
Mnexium AI
@ngburkeย Appreciate the inquery.
When a new chat message comes in, Mnexium performs a semantic search against the stored memories. Based on relevancy and similarity scores. The most relevant memories are provided to the LLM. So, yes it does use context space. We believe this trade off is worth it. since a few hundred tokens of highly relevant context dramatically improves response quality.
The alternative of stuffing the entire conversation history or all memories into context would be more expensive. It would also require storage, orchestration etc.
We tried to make this as intuitive and easy as possible. For example, you have the option to recall memories but decide whether it makes sense to include or not include chat history into an LLM request.
recall: true โ inject relevant memories into context
history: true | false โ include previous messages from this conversation
The reasoning for the above is that not all LLM requests will be neatly tied back & forth chat requests. You can make requests from different platforms, API calls, etc but as long as the subject_id remains consistent the LLM will know more about the user then not by using Mnexium.
We would appreciate any feedback as we are exploring what features to include and build next. For example history : True will include the entire chat history into the LLM request - if users find it useful we'd certainly be open to building summarization features into the request.
@marius_ndiniย Ok, understood. So you have a meta layer that helps guide what is most likely / relevant to pre-inject into context ... with some control at the user level. Makes sense, and yes I agree a little context use is worth alot in making the output way higher quality (and thus less back and forth eating up the context!).
The one thing I would be most worried about is your capability being copied / replicated / absorbed by the model makers themselves. It's also the one thing that would make me hesitant to try your product and invest time in learning it if I think it will become a normal feature in my current goto Claude Code. I don't say this to be negative, but giving some honest feedback. What would you say to someone like me?
Mnexium AI
@ngburke Totally fair question/concern as itโs something we think about a lot too.
We donโt want to compete with model providers. Mnexium is meant to enhance whatever model you use, by augmenting it to give it the necessary context to provide better outputs. I agree and we fully expect OpenAI / Anthropic to keep adding memory features. But those features will mainly be designed to make their ecosystems better โ not necessarily to give builders full control.
If/when they productize memory, it will likely live inside their stack. Mnexium is intentionally model-agnostic and independent โ the same memory layer can be used by ChatGPT, Claude, on-prem models, or open-source models. Our goal is that memory belongs to the builder, not the vendor.
Long-term, we want Mnexium to be an enterprise-grade memory platform โ something that can integrate with CRMs, ERPs, marketing tools, data warehouses, etc., and where developers control access, governance, and portability (in and out of the platform).
The future vision is that end-users can also own and manage their profiles/memories. Imagine you and I both have Mnexium profiles, and a travel agent app instantly understands preferences because itโs connected to that shared memory layer. I think thatโs a different problem than what model providers are solving. We then use another agentic app - which instantly has access to the shared memory layer. Long-term this provides a lot value to developers like yourself since your app instantly becomes smarter and more capable without you having to do any additional work. Model providers wont provide this level of access since I don't envision they'd give developers access to their users memories.
So even if vendors add memory features, we see Mnexium as the layer that stays open, portable, auditable, and under developer + user control. While also having the ability to increase experiences to devs and end-users.
I really do appreciate the question and the discourse -
The single API approach to persistent memory is appealing - managing vector DBs and retrieval logic can get complicated quickly. For agents that need to handle multiple users or different memory contexts, how does the subject_id isolation work? Is there a way to share certain memories across subjects while keeping others private?
Mnexium AI
@yamamoto7ย Appreciate you seeing the value of Mnexium.
Each subject_id creates an isolated memory namespace. Memories stored for subject_id: "user_123" are never visible to subject_id: "user_456". Currently, there's no built-in "shared memory" feature, but there are a few patterns you can use:
Global Subject ID - Create a shared subject like "global" or "shared_knowledge"
I'd give these IDs some kind of ID just to be safe like "GLOBAL_UUID" etc
System Prompts - For knowledge that should apply to all users (company policies, product info, etc.), you may use system prompts. These are scoped at the project level but can also be individually (by subject_id) as well as the chat level.
A proper shared memory layer (e.g., project scope vs subject scope) is something we're considering. The challenge is balancing retrieval relevance - shared memories need to compete fairly with personal memories during recall.
Would a shared memory scope be useful for your use case? Happy to hear more about your use-case and what are you looking to accomplish so I may best guide you.
Congrats on the launch, @marius_ndini!! Love to see VSCode integration to build a persistent memory without having to roll something custom. This would be a huge time saver and solve a massive pain point. Any plans for an extension? OpenAI only or will you be adding support for other LLMs? What about a containerized version you could run locally?
Mnexium AI
@braniforniaย Appreciate the suggestion. While I don't rule a VSCode integration out, we are being selective just given the amount of priorities we have to juggle.
Currently OpenAI is supported, Claude support coming soon as well. Ideally and in the near-term we would be completely model agnostic. So you may use Mnexium across all your apps whether they use ChatGPT, Claude, On-prem open source models etc. I can even see a situation where you can mix & match models and Mnexium sitting in the middle handling memories and infra.
I'd love to hear more about your VSCode pain point and that document.
From a design standpoint, Mnexium AI feels notably restrained.
Instead of over-signaling โAI intelligenceโ through controls or feedback, the interface seems focused on keeping users oriented and confident. That choice to reduce noise rather than add affordances is subtle, but it often makes the difference between an AI tool that feels usable versus overwhelming.
As a first impression, the design reads as intentional and user-respecting โ which is refreshing in this category.
Mnexium AI
@rexlianย ๐๐๐ Thank you
Appreciate the comment -
It means a lot since design (both UX and API) is a personal weak spot.
Mnexium AI
@jonathan_alonsoย We do not currently have an N8N node yet. Certainly would love to one day.
Today weโre fully usable via the HTTP Request node.
Please find our API docs here https://www.mnexium.com/docs