Most automation workflows can call a model, but still need substantial glue code for memory, personalization, and structured data. The Mnexium connector makes those capabilities native in n8n.
Mnexium memories are great for capturing facts, preferences, and context from conversations. But many AI applications also need to manage structured business data events on a calendar, deals in a pipeline, contacts in a CRM, tasks on a board, inventory items, support tickets.
Until now, you had two choices: build a separate database and API layer for your structured data, or try to shoehorn everything into unstructured memories. Neither is ideal.
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.
๐ง ๐๐ง๐๐ฑ๐ข๐ฎ๐ฆ = 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?
