You've felt it. You have a long, useful conversation with an AI assistant — it learns your project, your preferences, the details that matter — and then you open a new chat tomorrow and it's a stranger again. Everything's gone.
That's not a bug in one product. It's the default state of large language models: they don't remember. A model only "knows" what's in its context window right now. Close the window, start a new session, and the slate is wiped. For a chatbot that's annoying. For an agent — software meant to act on your behalf over days and weeks — it's disqualifying.
Two failures, not one
There are actually two distinct memory problems, and most fixes only address the first.
1. It forgets between sessions. No persistence across chats. Every conversation starts from zero.
2. It remembers too much, badly. The common fix is to store everything the AI is ever told and retrieve the similar bits later. But real information changes. A client's budget goes from £5,000 to £8,000. A launch date moves. A contact leaves. If your memory hoards every version, retrieval surfaces the stale one right alongside the current one — and the AI confidently answers with the old value. Store-everything memory doesn't just waste space; it actively serves wrong answers.
Why the obvious fix isn't enough
"Just add a cloud memory service" works for some. But it quietly rules out the people who need memory most. If you're building AI for healthcare, legal, finance, or government, your data legally can't leave your walls — so a memory layer that ships every fact to someone else's cloud is a non-starter. The result: the highest-value, most memory-hungry use cases are locked out of the easy option.
So the real requirement is a memory layer that is both persistent and private — one that remembers across sessions, keeps its answers current, and runs where your data already lives.
What a memory layer actually does
A memory layer isn't another chatbot. It sits underneath whatever model you use and gives it four simple operations: store, retrieve, update, discard. Your agent calls them as tools while it works. The model does the talking; the layer does the remembering.
The interesting engineering is in how it remembers. Two choices matter:
- Forget at write-time, not read-time. When a new value for something arrives, retire the old one as you store it, so recall never has to guess which version is current. The current answer is the only answer that comes back.
- Keep less, on purpose. Deduplicate what the agent re-hears, and don't hoard superseded values in the recall set. In our own benchmark (LongMemEval-S), this kept roughly half the facts of a store-everything baseline at comparable answer accuracy — and it's reproducible, which in a field full of unverifiable claims is the whole point.
Local by design, cloud-compatible by choice
The version we're building, Enki, runs on your machine. The facts you give it never leave the box. But it isn't walled off — it bolts onto any model, local or cloud, through a standard memory-as-tools interface (MCP). You get persistence and privacy and the freedom to use whatever LLM you want. That combination — sovereign but integratable — is exactly what a cloud-only memory service can't offer.
See it, don't take our word for it
There's a live demo you can try in about a minute, no signup: try.enkilabs.co.uk
- Tell it a fact, hit "next day" to open a fresh chat, and ask a question only memory could answer. A normal assistant starts blank; the Enki-backed one remembers.
- Then run the storage comparison and watch a keep-everything memory pile up while Enki quietly retires the stale facts — ending at half the footprint, still answering with the current value.
Enki runs on your machine, not someone else's cloud — and the head-to-head results are public and reproducible: github.com/stephen487/enki-benchmarks. The core has a UK patent application filed. The engine itself is in closed beta right now — there's a waitlist on the demo if you'd like early access.
If you're building agents that need to remember — especially somewhere the data can't leave — I'd love your feedback. Try the demo, break it, and tell me what's missing: steve@enkilabs.co.uk.
Top comments (0)