AI Memory Beyond RAG: Vectors, Graphs, and Dense Mem

Justy The useful line in this thing is basically: RAG can find stuff, but that does NOT mean your system remembers it.

Cody Yeah. And honestly, I like that he starts by untangling the word memory, because people mash together context windows, vector search, and long-term state like they're one box.

Justy Which is such an Exploring Next problem, by the way. Episode four thirty-three and we're still out here asking whether a search result counts as a memory.

Cody His actual argument is narrower than the title makes it sound. He's not saying RAG is bad. He's saying stateless retrieval is the wrong primitive if the job is knowing what changed, what conflicted, and what should win now.

Justy Right. That's why it felt practical to me. If a product only needs, like, "find the README chunk about the port number," cool, RAG is fine. If it needs "remember my latest preference and don't blend it with the old one," that's a different class of problem.

Cody Exactly.

Justy Also, very small life update before we become unbearable. My flight was weirdly early, I got maybe five hours of sleep, and your coffee situation is still aggressively serious. I opened one cabinet and it looked like a lab supply closet.

Cody I mean, that's fair. I did spend an annoying amount of time this week dialing in a grinder because one setting drifted and every cup tasted flat. Which is, annoyingly, kind of the same point as this article. Tiny setup choices wreck the result and then people blame the model.

Justy That is the most Cody bridge back to the topic imaginable.

Cody The Claude Code section is good too. He calls that kind of memory startup context. CLAUDE dot M D files and auto notes get loaded into the session, but they're visible instructions, not a searchable semantic store.

Justy Mm-hm.

Cody So if somebody says, "we have memory because the assistant loads notes at the start," maybe, but only in the loose everyday sense. It doesn't give you conflict resolution.

Justy That's the part product people should care about. Users don't care whether it was context, retrieval, or a graph edge. They care that the assistant saw the newer note and still picked the stale one.

Cody Right, right.

Cody And his RAG explanation is refreshingly un-mystical. Documents become chunks, chunks become embeddings, embeddings go into an index, then the question gets embedded and you pull nearest chunks. But chunking, overlap, metadata filters, neighboring chunk retrieval, reranking... that's the actual behavior.

Justy Which matters because people talk about RAG like it's one product setting. Not some generic "AI searched the docs" story.

Cody Yeah.

Cody The embedding bit is solid too. He pushes back on the fake intuition that each dimension is a named concept. They're latent coordinates. More dimensions can help preserve signal, but a bigger embedding from a worse model can absolutely lose to a smaller one that's better matched to your domain.

Justy I appreciated that because there's always a product deck somewhere going, "bigger vector, better memory," and... no. That is such a clean way to buy an expensive mistake.

Cody Anyway. Where the article gets strongest is the line that vector search returns candidates, not truth. That's semantic recall. It is not a current-state policy engine.

Justy So then the graph piece isn't "graphs are magic now." It's that memory has relationships. Who said it, when, for which project, whether it's evidence or accepted fact, whether it conflicts, whether an older thing got replaced.

Cody Oh interesting.

Cody Yeah, and I think he stays disciplined there. He even says it's too broad to claim graph plus vector is simply more accurate or faster than RAG. Better chunking helps retrieval precision. Better embeddings help semantic match. Graphs help provenance and multi-hop relationships. Clarification flows help when memories conflict.

Justy That restraint made me trust the piece more. And the Dense-Mem example is useful mostly as an architecture boundary. The host model can notice candidate memories, but the memory layer owns storage, provenance, conflict checks, and recall. Raw evidence doesn't instantly become a fact.

Cody Sure.

Justy That's practical. If I'm building an assistant for support, project work, or personal workflows, I should care the second memory has consequences. If a wrong recall is just mildly annoying, plain retrieval is probably enough. If a stale recall changes behavior, now I need gates.

Cody I think that's exactly where the article holds up. My only tiny hesitation is that graphs can get messy fast if the extraction layer is noisy. He kind of says that, to be fair. A polluted graph is just a more structured mess. So the hard part is still policy, not database branding.

Justy And there is your weekly reminder that Cody cannot encounter a promising architecture without immediately imagining its failure modes.

Cody Yes, because the failure modes are where the invoices come from.

Justy Brutal. Also true. Anyway, my takeaway is pretty simple, Cody. Stop calling every retrieval stack memory, and stop promising durable recall if all you've built is really good search with vibes.