ML/AI & Security
Memora MCP: wiring Microsoft Research's Memora into a coding agent
An experiment wiring Memora, Microsoft Research's memory representation that searches on compact cues and returns detail verbatim, into coding agents over MCP.
Memora MCP is an experiment. It wires Microsoft Research’s Memora memory system into coding agents (Claude Code, Codex, Cursor, and the Omnigent meta-harness) through the Model Context Protocol. The question is plain: if the harness could remember what you established in past sessions, how much of the re-explaining goes away? I do not have a benchmarked answer yet. This post covers the setup and the hypothesis.
What Memora does differently
Persisting context across sessions is not the hard part, and it is not new. The hard part is the representation. Store prior conversation and reload it into the context window and the cost grows with the history. Keep compressed summaries and you lose the specific detail that made a note worth keeping. Memora is Microsoft Research’s attempt at that tradeoff, and it is the reason this experiment uses Memora rather than a plain vector store.
The paper, Memora: A Harmonic Memory Representation Balancing Abstraction and Specificity (Menglin Xia, Xuchao Zhang, and colleagues, published at ICML 2026), frames it as a forced choice: abstract memory so it scales as it grows, or preserve fine-grained detail, but not both. Their representation separates the two. Each memory entry has a short primary abstraction and several cue anchors that get indexed and searched, plus a full value that is stored verbatim and returned on a hit but never embedded through its own content. You match against compact, well-defined handles and get back the uncompressed detail.
Microsoft reports state-of-the-art results on the LoCoMo and LongMemEval long-term-memory benchmarks, and describes large token savings versus reloading full conversation history. Those are their numbers on their benchmarks, not mine, and I have not reproduced them. What I take from the paper is the structural idea, the part I can use: because the raw value is never embedded, storing a marginal memory does not blur retrieval the way padding a RAG index does. That makes it reasonable to store generously and let recall rank at retrieval, instead of filtering hard before writing.
What Memora MCP does
The bridge is small by design. Memora is a Python library with a good memory representation and no notion of where memories come from or which agent should see them. MCP is the standard that lets an AI application connect to external tools and data over one interface, the way Claude Code already talks to other servers. Memora MCP is an MCP server that puts Memora behind that interface.
The server exposes memory as tools an agent can call directly: memory_search, memory_save, memory_get, memory_forget, and memory_list. Capture and recall run on their own through hooks. When a session ends or compacts, a background turn on a cheap model distills the durable facts (decisions, config discoveries, a failure and its fix, a stated convention) and writes them into Memora’s store. When a new session starts, the memories relevant to that project get injected into the opening context, ranked by relevance and framed as reference rather than instruction. Recall is embedding-only and runs on a bundled in-process model, so the read path needs no API key and no service. The one model cost is capture, roughly once per session, in the background.
The main design choice: memory runs on whatever already runs your agents. On a logged-in Claude or Codex subscription, distillation runs as a background turn on the plan you already pay for, and embeddings run on-device, so the default install provisions no new key, account, or daemon. I kept Memora’s store and retrieval unchanged, since that is the benchmark-proven part, and replaced only its conversational extractor, whose prompt is tuned for personal-assistant chat and ignores assistant turns. For coding work the assistant’s reasoning is exactly the content worth keeping, so the extractor is domain-tuned and emits Memora-shaped entries into the store underneath.
Building against Memora’s current checkout turned up a handful of rough edges (a query mode that discards primary hits when the cue leg is empty, caller metadata that is accepted but never persisted, a where filter that gets overwritten instead of AND-ed). Those are documented in the repo as upstream findings, worked around at this layer rather than by forking.
The hypothesis
If a coding harness carries persistent semantic memory across sessions, three things should follow. Continuity: a decision made on Tuesday is still known on Friday without me restating it. Learned project context: the conventions, the config facts, the failure modes specific to a repo accumulate instead of evaporating. Less re-explaining: the opening context of a new session already contains the relevant priors, so the first few turns are not spent rebuilding what the last session already knew. And because it runs through one shared store, a fact learned while working through Codex should be recallable in Claude Code the next day.
That is the claim I want to test. It is not proven, and there are real reasons it might underdeliver. Local-embedding recall is strong on close paraphrases and weaker on far conceptual leaps. A generous capture policy stores more marginal notes, and whether that helps or just adds noise is exactly the thing to measure. Automatic extraction can miss an important fact or keep an unimportant one. As it stands, the plumbing works (there is a round-trip check in the repo that saves a fact through the real server and retrieves it from a fresh process with a keyword-free paraphrase), and whether it measurably reduces re-explaining over weeks of real work is still open.
The suite is MIT-licensed and independent of both Microsoft and Databricks. Code, the design overview, and the setup are in the repo.