We hit 99.95% on the LoCoMo memory benchmark. Here's the catch, and why it still matters.

Our CEO Rob Imbeault published a piece on LinkedIn this week about a result our team posted: 99.95% on LoCoMo, the most cited benchmark for long-term conversational AI memory. His version is written for executives and CISOs. This is the developer version, because the interesting part isn't the number. It's how we got it, and what it says about where memory architecture is heading. (Credit where it's due: the ideas here are from Rob's original article. The translation to dev-speak is mine.) The catch, stated upfront We didn't get 99.95% with retrieval. We got it by post-training the memory directly into the model weights, and we trained on the same conversation set the benchmark tests. On purpose. So no, this doesn't prove our model is "better at memory" than yours. It was never meant to. The experiment measures the ceiling of parametric memory: when you teach a model a corpus of conversations, how well can it recall and reason over them with zero retrieval machinery? The answer turns out to be: near-perfectly. That result matters because the technique behind it just became cheap. And that changes the architectural conversation for everyone building on LLMs. The problem: every LLM app has goldfish memory You know the drill. The model forgets everything when the conversation ends, so we all built the same workaround: chop conversations into chunks, embed them, index them, and at query time search the store and staple the relevant chunks to the front of the prompt. RAG. It works. Almost every "AI with memory" product ships it. But it has three structural costs that show up at scale: The token tax. Every query re-sends the same context. Customer history, policy docs, prior decisions, reloaded and re-billed, forever. Shared-store leakage. Isolation in a shared vector store is a config property: a filter, a tag, a permission check. Config fails. The industry's incident list of one tenant's memory surfacing in another tenant's session keeps growing. Silent retrieval failures. Grab the wrong chunk and the model confidently answers the wrong question. No stack trace, no error, just a wrong answer. ## The other approach: teach it into the model Post-training used to be expensive and exotic. In 2026 it isn't. LoRA makes the teaching efficient. Quantization (our BBQuant work lives here) shrinks the result without meaningful quality loss. Together they've turned post-training from a research project into something a small team can run as a routine operation, on modest hardware. Teach the corpus into the weights and the properties flip: No token tax. The memory lives in the model. You pay a one-time teaching cost, then queries are just queries. Isolation by construction. Each tenant gets their own weights. One tenant's model physically cannot see another tenant's data. There's no shared store to misconfigure. It's a file. A model with its memory baked in runs on a laptop, a factory-floor box, or an air-gapped server. Nothing phones home. The trade-offs are just as real, and you should weigh them honestly. Updating is slower than a database write. Deleting a specific fact is genuinely hard, which matters under GDPR and PIPEDA right-to-be-forgotten regimes. And parametric memory is better at recalling what it was taught than reasoning about brand-new conversations it has never seen. Measuring it properly: LoCoMo-Δ Because we trained on the test material, recall and generalization are tangled together in our 99.95%. The benchmark as it stands can't separate them. So alongside the result we're proposing LoCoMo-Δ, an extension that holds conversations back from training, letting the field measure recall and generalization independently. Benchmarks only mean something if they measure the right thing. If you work on memory or eval design, we'd like your eyes on the protocol. The math for repeated workloads Here's the part I find most interesting as an engineering decision. For any corpus that gets queried repeatedly, there's a crossover point where one-time teaching beats per-query retrieval. Depending on corpus size and query volume, that crossover lands somewhere between hundreds and thousands of queries. Support bots, internal knowledge bases, sales enablement, compliance Q&A: most of these clear that threshold in about a week. The cost curve everyone assumes is fixed ("memory = tokens forever") is only fixed because retrieval was the only tool on the shelf. The honest architecture: both This isn't "RAG is dead." The right answer is deliberately splitting the job: Parametric memory for stable, high-value, per-tenant knowledge: playbooks, policies, product knowledge, recurring customer context. The stuff a new hire eventually internalizes and stops looking up. External memory for volatile, user-owned, or regulated data: recent transactions, preferences, anything that must be edited, deleted, or audited on demand. Most systems today use retrieval for both jobs. Not because anyone chose that, but because nobody offered the choice. What we're releasing This is the part that should matter to you even if you never touch our platform: The post-training recipe we used, reproducible on modest hardware A BBQuant-compressed checkpoint small enough to run on a high-end laptop The LoCoMo-Δ protocol proposal for the research community Watch github.com/backboard-io for the drops. The 99.95% is the headline. The real story is that the tooling to get there quietly became accessible to almost everyone. If you're building anything with long-lived context, the memory architecture decision is now actually a decision. Better to make it on purpose than inherit it from whichever vendor you started with. We're a small Canadian team at Backboard building model-agnostic AI infrastructure, and we like showing our work. If you disagree with any of the above, the comments are open. That's what they're for. Original article: When Your AI Remembers: A New Way to Think About Memory in Enterprise AI by Rob Imbeault, CEO of Backboard.