We have started calling a lot of things "memory" that are not memory. RAG is called memory. Knowledge graphs are called memory. Vector databases get sold as the memory layer for your agents. They are all genuinely useful, and none of them is remembering.
They are retrieval. You hand the system a query, and it hands you back the pieces that scored closest to it. That is a search box with extra steps. It is not the thing your own mind does when you remember.
What memory actually is
Think about how memory works for you. You pull on one thread, a name, a date, a single fact, and you think on it, and then everything else comes back together around it. The meeting where you first heard the name. What was decided. Who disagreed. The document it was written in. You did not ask for each of those pieces one at a time. You pulled on one, and the connected whole reassembled.
That reassembly is the entire point, and it is exactly what retrieval does not do. Retrieval fetches what you asked for. Memory brings back what you did not know to ask for.
Once you hold that as the bar, it becomes obvious why the usual candidates fall short.
Why RAG isn't memory
RAG does its thinking at query time. You ask a question, it turns the question into a vector, finds the chunks that sit nearest in embedding space, and drops them into the model's context. It never understands the material. It fetches lookalike text on demand, from scratch, every single time. There is no accumulation, no reassembly, no sense of how anything connects. It is similarity search wearing a memory costume.
Why a knowledge graph isn't memory
A knowledge graph goes the other way and tries to model everything up front. You decide in advance what the entities and relationships are, force the world into a schema, and then maintain that schema forever as reality drifts out from under it. It is a heavy, brittle exercise, and worse, it throws most of the meaning away. Collapsing a document into nodes and edges keeps the skeleton and discards the flesh. And even once it is built, querying a graph is traversal. It is still retrieval, just with a prettier map.
Why a vector database isn't memory
A vector database is plumbing. It stores embeddings and returns nearest neighbours, quickly and at scale, which is valuable. But nearest-neighbour lookup has no understanding of what it holds and no notion of context reassembling around a recalled fact. It is a very fast way to find similar things. Finding similar things is not remembering.
What memory requires
If memory is understanding that persists and reassembles on a pull, then a system that has it needs three properties the retrieval stacks lack.
It has to understand once, up front. Not at query time, when you are in a hurry and paying for every token, but at ingest, when the material first arrives. Read it properly, work out what it means, and keep that.
It has to hold the connections without flattening the source. Entities, facts, and how things relate, but anchored back to the real document, not replaced by a stripped-down graph of it. You keep the flesh, not just the skeleton.
And it has to reassemble on a pull. When an agent reaches for one thread, an entity, a fact, a file, the related context should come back with it, compact enough to think on, with the full material one step away for when the summary is not enough.
How we built it
This is the thesis Find and Seek is built on. When a file lands, on-device models read it once and build a durable layer of understanding: what it is, the entities and facts inside it, how it connects to everything else, all anchored to the source. That understanding stays. So when an agent pulls on a thread, the connected material comes back together, served as a compact card it can reason over, with the full context available the moment the card is not enough.
All of it runs on hardware you control. Nothing about your files leaves the machine.
The cost drop that comes out of this is real, and worth stating plainly: over a 2,500-file corpus, working from reassembled cards instead of dumping whole documents into context meant 56% fewer input tokens for the same work, about half the cost. But that is a consequence, not the reason. The reason is that an agent that remembers, instead of re-reading everything every time, is simply working the way a mind does. The savings are just what that looks like from the outside.
Retrieval finds. Memory reassembles. If you have been calling your retrieval stack a memory layer, it is worth asking which one you actually have.