Memora: an MCP memory layer with absorb, supersession lineage and multi-database routing

The problem Memora targets: an agent that forgets between sessions

An MCP client starts a fresh context every session. Anything the agent learned last week, including the decision it made and the reason it rejected the alternative, is gone unless someone wrote it into a file the agent reads again. Memora positions itself as that file, but with structure: facts go in as records, not as prose appended to a markdown document. The README describes the target as "persistent collective memory" for agents, and the feature list backs that up with typed edges, sections and subsections, TODOs, issues, and source IDs on retrieved memories. The audience is narrow and specific. You need to be running an MCP-capable client, since the whole interface is MCP tools. The README names Claude Code and Codex among its topics, and the badge mentions Awesome Claude Code. If your agent stack does not speak MCP, Memora has nothing to attach to. The second requirement is that you care about the history of a fact, not just its current value. A plain vector store answers "what is similar to this query." Memora additionally answers "what did this fact used to say, and what replaced it," which is the part that maps onto how engineering decisions actually change.

Absorb, classification, and the supersession chain

The absorb path is the mechanism worth understanding. You feed facts in, and an LLM classifies each one against the existing store into one of five buckets: duplicate, update, contradiction, related, or new. Duplicates are skipped rather than stored twice. Relations become edges. Related facts get consolidated. There is a `dry_run` flag so you can preview the classification before it commits, which matters because the classifier is an LLM and will occasionally disagree with you. Updates do not overwrite. They supersede: the old record stays in the store and the new one points back at it, forming a lineage chain. Retrieval then walks that chain, and the `follow` parameter decides where it stops. The README lists three modes: `active`, `latest`, and `full_history`. That is a real design choice with a real cost. You keep the audit trail of how a fact evolved, and in exchange your store grows monotonically, because nothing is deleted. A fact revised weekly for a year leaves fifty-two records in the chain. The `full_history` mode will return all of them. Whether that is a feature or a storage problem depends on how often your agents revise the same facts, and the README does not offer a compaction path for superseded records that I can find in the supplied material.

Getting it running: pip, .mcp.json, and the memora-server binary

The local install is one command: `pip install memora-mcp`. The package name on PyPI is not the project name, and the README is explicit about why that matters. Bare `memora` on PyPI belongs to an unrelated project, so installing the wrong name gets you someone else's code. Cloud storage (S3, R2) and OpenAI embeddings are included in the base install. Local embeddings are an extra: `pip install "memora-mcp[local]"`, which the README notes pulls roughly 2GB for PyTorch. There is also a git install for the development version. Once installed, the client spawns it from `.mcp.json` with `"command": "memora-server"`. That string is the contract between the package and your client config, and it is the first thing to check after installing, because a mismatch there produces a client that silently has no memory tools. Configuration beyond that covers storage location, embedding backend, and the multi-database setup described below.

The container path assumes Apple silicon and macOS 26

The second install route is a detached HTTP service rather than a stdio child, and it is where the constraints pile up. The default runtime is Apple's `container` CLI. The README states that this needs a Mac with Apple silicon running macOS 26, and that Apple does not support older macOS versions for `container`. That single sentence rules out the container path for Linux servers, Intel Macs, and any Mac that has not been upgraded. The setup sequence is: install the signed pkg from Apple's releases, run `container system start` (which also installs a kernel if none is configured), clone the repo, copy `instances/example.env` to `instances/myinstance.env`, then edit `PORT` and one backend among `STORAGE_URI`, `VOLUME`, or `MEMORA_DATABASES`. The template ships with `INSTANCE=myinstance` so the later `build`, `up`, and `proxy` commands match without renaming. Every container operation in `scripts/memora-instance.sh` goes through `$MEMORA_CONTAINER_BIN`, which defaults to `container`. The exception is the generated proxy process, which hardcodes `container list` and therefore ignores that variable. If you point `MEMORA_CONTAINER_BIN` at a different binary, the proxy is the piece that will not follow.

Multi-database routing and the LaunchAgent restart gap

Version 0.4.0 is labelled "multi-database," and the README describes the shape: one process serves many stores, and a workspace reaches its own at `/mcp/<name>`. The configuration key is `MEMORA_DATABASES`. This is the feature that makes the HTTP path worth the install cost, because a single long-running service can back several projects without each project starting its own process. The README also documents a failure mode that is easy to miss and unpleasant to debug. The LaunchAgent supervises the proxy, not the container. After a host restart, the listener can come back while its upstream is still stopped. From the client's side that looks like a reachable endpoint that returns nothing useful. The README's own framing is blunt: if you are running Memora as a service, the container path is the install, not an alternative to one. That is a fair statement of the trade-off. The pip path is simpler and has no supervisor to get out of sync, but it is one process per client and it does not do multi-database routing.

Search backends, document fragments, and what the material does not settle

Semantic search supports three embedding backends: TF-IDF, sentence-transformers, and OpenAI. TF-IDF is the one that works with no model download and no API key, and it is also the weakest of the three at matching paraphrases, which is the whole point of semantic search. The README does not state how recall compares across the three, so the choice is yours to measure on your own corpus. Documents take a different route into the store. A markdown document is stored as a fragment tree of claims, plan items, references, and risks, and each fragment is individually searchable while the full document remains retrievable as a unit. The README describes fragment integrity guards against accidental delete, merge, or absorb of document fragments, which suggests the authors hit that bug and fixed it rather than designing it away. `memory_digest(topic)` is the retrieval entry point the README promotes: it bundles relevant memories, open TODOs and issues, related edges, and source IDs into one call. The source IDs are what let you trace a retrieved claim back to the thing that produced it. What the material does not settle: how the LLM classifier behaves when the store is large, what happens when classification is wrong and you want to undo it, and whether there is any compaction for superseded chains. I cannot confirm those from the README, so treat them as questions to answer on a test store rather than assumptions.

Where Memora is the wrong tool, and what to use instead

Memora is the wrong tool when you want one shared memory across a team of humans as well as agents, or when you need a hosted service with an uptime commitment. It is a self-run MCP server backed by SQLite, with optional sync to S3, R2, or D1. If nobody in your team will run the process, nothing works. The natural alternative is a plain vector store paired with a retrieval script: embed chunks, write them to a local index, and have the agent query it. The difference in approach is the write path. A vector store treats every write as an append and leaves conflict resolution to the reader. Memora classifies each write against the existing store before it lands, so duplicates never enter and contradictions become lineage rather than two competing chunks that both surface in a similarity search. That classification step is also the cost: it needs an LLM in the loop, it can be wrong, and it makes the write path slower and more expensive than an embed-and-insert. If your agent memory is mostly append-only notes that never contradict each other, the classifier is overhead you are paying for nothing. If your agents routinely revise the same facts, the lineage is the reason to pick this over a bare index.

Editorial conclusion

Adopt Memora if you already run MCP clients such as Claude Code or Codex and you want agent facts to accumulate across sessions without deleting the old version of a fact. Skip it if you need a hosted service with a stability guarantee, or if your machines are not Apple silicon on macOS 26 and you were planning to use the container path rather than pip. Before committing, verify three things against your own install: that `pip install memora-mcp` gives you the `memora-server` binary your `.mcp.json` expects, that your chosen embedding backend is reachable (TF-IDF needs nothing, OpenAI needs a key, the local extra pulls roughly 2GB of PyTorch), and that the `follow` mode you pick (`active`, `latest`, or `full_history`) returns the version of a superseded fact you actually want to see.

Official sources

1. agentic-box/memora on GitHub
2. Issues
3. License: MIT
4. README
5. Releases