memorix

A multi-layer memory SDK written in Go. It sits on the LLM call path as middleware: before the request it recalls relevant memories and injects them into the system prompt; after the response it extracts new memories asynchronously and writes them back. Memory is organized in four layers — working, episodic, semantic, and procedural — with global and local scopes for multi-agent use. Storage is SQLite or in-memory; the embedder and LLM are pluggable.

Repository: github.com/chuhanshao/memorix

I built it around a few questions I couldn’t answer:

• Without ground truth, what do you measure memory retrieval quality against? Ask two annotators which memories a given turn should recall and you get two different lists.
• How much of “hybrid retrieval beats pure vector search” holds on memory workloads? It’s a common result in the retrieval literature, but for the memory setting I couldn’t find data I could cite directly.
• The four-layer design has more write and recall paths than a single store. What does that complexity buy?

The SDK leaves room to run these experiments: fusion strategies are an explicit enum, and FusionVectorOnly is kept alongside RRF (k=60, Cormack et al. 2009) as the pure-vector control baseline. One trade-off measured so far: Consolidate() loads a single user’s entire episodic layer into memory, which stops being viable once the volume gets large.

The README has the complete list of remaining limitations. This project was built with heavy AI assistance, has never been independently audited, and has never carried production traffic, which is why the README opens with “Do not use in production without conducting your own independent review.” That line is still accurate, and I don’t plan to remove it.