Last time I described the hour a platform shipped the feature I had spent months building. This is the part where I ran the test instead of the emotions, and found two things that were never competing.
One number up front, because it qualifies everything below: this is still one user. Every figure here comes from my corpus, my questions, my four servers. The method transfers. Whether the result does, I cannot tell you yet.
The test from last time is one question: teach it a fact only true in your world, close everything, come back in a fresh session, and count how often the fact comes back.
Both passed. That was the first surprise, and it is worth saying clearly: the built-in memory works. This is not a post about a competitor being bad.
The difference showed up when I changed one thing in the test. I asked the fact from a different editor.
And then again from a different machine. And then I asked a colleague to ask it.
That is where the two answers stopped matching, and it had nothing to do with quality. It had to do with what each thing considers its own boundary.
Here is the distinction I could not put into words on that bad evening, and it took a test to produce it.
A vendor's memory is bound to the vendor's harness. It makes one assistant continuous with itself. That is genuinely valuable and it is what most people mean when they ask for memory.
What I had built is bound to the repository instead. It makes the knowledge about a codebase continuous — across editors, across machines, across people, across model upgrades.
Those are not two implementations of one feature. They are answers to two different questions. "What did I just say?" and "what does this project know?" only look similar until you switch tools.
The clearest way to see it: when someone leaves your team, a session memory leaves with them. A project memory does not, because it was never theirs.
The four boundaries above are about where memory lives. There is a fifth one, and it is about how you find anything in it — I only understood it because someone else wrote it down.
Think about the two entries that matter most together: an error, and the fix that was found three weeks later. Write them out.
Those two share almost no vocabulary. One is a symptom, one is a cause; one is about a build step, one is about a disk. In embedding space they sit far apart — not slightly, structurally. And they are the single most valuable pair in the whole store, because together they are the answer and apart they are two anecdotes.
A similarity search cannot connect them. Not because the embeddings are bad. Because semantic closeness and causal connection are different relations, and only one of them is what a vector index measures.
That is why our store keeps a causal path beside the similarity one — which entry led to which, which contradicts which. I had treated that as a secondary feature for a long time. It is the part that similarity cannot do, and I needed an outside article to see it.
This also cuts against my own product, so I will say it plainly: if what you need is "find me the thing that sounds like this", a vector search over a file does that, and the extra machinery earns nothing.