Mnexium

Just published a new case study on Cartly, an iOS app that uses Mnexium to power a full receipt-tracking AI workflow. We really wanted to see what it would take to get a demo like this up and running.

In the post, we walk through how Cartly uses:

Memory for user preferences and continuity

Records for structured receipts and receipt_items storage

A single mnx runtime object to control identity, history, recall, and record sync

Request trace packets for auditability and debugging in production

The demo flow covers schema setup, receipt image capture, AI extraction, record persistence, and record-aware chat responses.

Blog: <https://mnexium.com/blogs/introducing-cartly>

Docs: <https://mnexium.com/docs>

iOS code: <https://github.com/mnexium/cartly>

Today we’re open-sourcing the core memory engine behind Mnexium.com : CORE-MNX

GItHub (https://github.com/mnexium/core-mnx) NPM (https://www.npmjs.com/package/@mnexium/core)

For us, this is a product decision and a philosophy decision.

Memory infrastructure is becoming foundational for serious AI products, and we believe the core layer should be transparent, inspectable, and extensible by the teams building on top of it. We also just want feedback - we want to build the best memory system given the tools we have access to today. We also want to make LLMs perform better then they already do OOTB.

CORE-MNX is the backend layer that powers durable memory workflows: memory storage and retrieval, claim extraction and truth-state resolution, memory lifecycle management, and event streaming for real-time systems. It’s Postgres-backed, API-first, and built to integrate into real production stacks.

We tried our best to make this system as standalone as possible. Ultimately, its fairly difficult we needed LLMs (Cerebras for fast token output, ChatGPT for intelligence etc), Databases for storage etc. We have intentionally made the project API interfaced so your project can be code agnostic.

Open-sourcing CORE lets builders: understand exactly how memory behavior works, self-host or extend the engine for their own products, and avoid reinventing the same memory infrastructure from scratch.

What stays on Mnexium.com Mnexium’s long-term direction is still the same: make AI systems more useful over time through durable memory and reliable recall. We've just figured out that hosting memory isnt the moat we once thought it was - the real moat we believe is making the LLM system(s) as easy to use as possible. The feature-set we've built around memory is what is differentiating.

Open-sourcing CORE is how we make that foundation available to everyone building in this space. Open to everyone to lend an opinion on improvements and how we make this problem solvable.

Would love feedback, opinions and bugs you may find. We release it isn't perfect, but certainly a good start we'd love to improve upon.

I've spent the past couple of months building Mnexium.com

Originally it was supposed to just be a memory management system (and it still is very much core).

I was thinking with all of the talk of AI replacing SaaS etc etc... How?

Most (if not all) AI systems do not have a way to manage, store & maintain records. I thought it would be an interesting project and problem to solve.

I built it into the overall project more details here (https://www.mnexium.com/blogs/introducing-records).

I've realized it is nearly impossible to get some kind of feedback on these types of projects.

I really just want people to lend their opinion.

This is needed? This is not needed? Needed but implemented incorrectly. etc

Happy to answer any questions -