For curiosity's sake, have you had it try to attempt captchas?

If so, what were the results?

Difficult just to get feedback. This seems like a cool project, I dont have a ticketing system otherwise i'd try it.

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:

Docs:

iOS code:

Comments URL: https://news.ycombinator.com/item?id=47222351

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=47088761

Points: 1

# Comments: 0

New entrants being folks outside the model providers themselves? I do think the database layer can be decoupled from the memory/creation layer

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 -

Comments URL: https://news.ycombinator.com/item?id=47038114

Points: 1

# Comments: 2

It handles persistent chat history, long-term semantic memory, user profiles, agent state, and rolling summarization.

It sits between your app and the model and works across OpenAI, Claude, and Gemini — you can switch models without losing context and still maintain memories.

The goal is to stop every team from re-implementing slightly broken memory systems, and to make memory user-owned and portable instead of tied to a single model or vendor.

Currently live with JS/TS and Python SDKs. Looking for feedback if anyone has any - good idea, bad idea? etc.

https://mnexium.com