Memory is infrastructure, not a framework.

The problem we kept hitting

LLMs forget. Context windows fill up. Important details get lost. Your chatbot asks the same question twice and your agent loses the thread between turns. The standard response — stuff more tokens in, hope for the best — stops working the moment the conversation is non-trivial or the user comes back tomorrow.

The next standard response is "throw a vector DB at it." That works for a while, then the limitations show up: no notion of who or what the memory belongs to, no way to scope retrieval to a topic, no recency, no importance, no token budget. The vector store gives you nearest-neighbours; it does not give you memory.

What we built instead

Memorg organises memory hierarchically. A session belongs to a user. A session holds one or more conversations. Each conversation has topics, and topics hold exchanges — message pairs between user and system. The same hierarchy holds arbitrary memory items: documents, notes, anything you tag.

Storage is SQLite via aiosqlite, so the whole thing is one async-friendly file you can copy. The vector index is USearch, embedded in the same store. Embeddings come from OpenAI. The package ships an MCP server (FastMCP) so MCP-aware clients can read and write Memorg directly.

Retrieval blends three signals: semantic similarity from the vector index, recency, and an importance score. Results are trimmed to a token budget you set when you create the session. That is the whole shape.

What it deliberately is not

Memorg is not a framework. It does not own your prompts. It does not run your agent loop. It does not include a router or a planner or an evaluator. You can use it from a single async function in a Flask handler or wire it into any orchestrator you already prefer.

Memorg is not a hosted service. It runs in your process, reads and writes a file you own, and talks to OpenAI for embeddings. If you need a managed offering with multi-tenant isolation and a control plane, this is not that — yet.

Memorg is not a multi-vector-DB abstraction. The vector store interface is small and pluggable, but the default — USearch in the same file as SQLite — is good enough that most teams will never need to swap it. We resist adding adapters until there is a clear reason to.

Where it fits

The target users are app builders shipping LLM-backed chat where the conversation matters beyond a single turn, and RAG teams who have outgrown naive vector search and want a layer that understands users, sessions, and importance. If you are running a one-off completion with no continuity, you do not need Memorg. If you are juggling a chat history table, a vector store, a summary prompt, and a tag dictionary, you probably do.

The cognitive ergonomics

The visual identity for the site — Atkinson Hyperlegible for everything, sapphire and ember on ink, generous line-height — is deliberate. Memory is a cognitive subject, and the canonical font for cognitive accessibility happens to be one of the most legible body fonts available. We wrote the marketing site in it because we want the reader to actually finish a paragraph.

License and lineage

Memorg is MIT-licensed. The package is published on PyPI as memorg. Source lives on GitHub under neul-labs/memorg. The project is in alpha — the data model and retrieval API are stable enough to build on, edges are still being smoothed. Pull requests are welcome; please open an issue first for anything larger than a fix.

Who is building it

Memorg is a Neullabs project. We build small infrastructure libraries we wished existed when we were shipping LLM apps. If a piece of plumbing should exist as a boring library, we would rather build the library than ship a framework.