As out platform continues to grow and captures more of an AI workload. There will always be new features & improvements we can make. This is one of those, we've always had and seen a need in the platform to direct and instruct our memory generation layer. This is what memory polices offers - the ability to guide Mnexium's memory layer.
Why Memory Policies?
Not every app wants to memorize everything. Some teams need strict extraction rules for compliance, quality, or cost. Others need per-workflow behavior, like high-signal extraction in support chats and minimal extraction in casual chats.
We just shipped @mnexium/chat: a single npm package that adds a polished, production-ready AI chat widget to any website. React, Next.js, Express, or plain HTML it just works, and most importantly it remembers.
Most AI memory systems treat all memories equally. Something mentioned two years ago carries the same weight as yesterday's conversation. That's not how human memory works and it creates awkward, irrelevant AI responses.
Today we launched Memory Decay, a feature that makes AI memory behave more like human memory. Frequently used memories stay strong. Unused ones naturally fade. The result is more relevant, contextual AI interactions.
๐ง ๐๐ง๐๐ฑ๐ข๐ฎ๐ฆ = 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.
When people talk about AI memory, it s usually framed from the developer s side. How do we store it? How do we retrieve it? How do we keep context alive? This is where @Mnexium AI started as well since that ecosystem is important.
But the initial vision and goal was very different and yet to be executed on.
What if users owned their memories not just the app owners?
