You ask your agent why you stopped using that HTTP client. It comes back with three memories, and all three are about the client. One says you adopted it in March. One is a note about its retry defaults. One summarises a session where you argued about timeouts for an hour. Every line is true, and you wrote all of them. None of them answers the question, because the answer was never inside a memory. It was in the step from the timeout argument to the incident, and from the incident to the decision. The agent kept every stop on the route. It threw away the road between them.

The danger is never in one box

Think about the counter of a pharmacy. Knowing each medicine is the easy part, and it is not what makes the counter safe. What makes it safe is the second question: what else are you already taking, when did you start it, and who put you on it. The box in your hand is inert information. The risk, and the whole of the pharmacist’s value, lives in the relation between that box and the ones already in your cupboard.

Graph-augmented associative memory is built on that instinct. It keeps episodes verbatim, the conversation as it actually happened, then pulls out atomic facts and concept nodes, and finally writes higher-order reflections on top. Retrieval fuses two moves: nearest neighbours by cosine similarity, as in any vector store, and a Personalized PageRank walk that is sensitive to the type of the edge it is crossing. The concept nodes matter more than they look. A graph built on entities alone grows mega-hubs — the name that appears in everything, connected to everything, and so telling you nothing. A concept like “concise technical summaries” cuts across, so a question about your style can reach the facts and reflections hanging off that idea instead of drowning in whatever entity you happen to mention most often.

A why question needs a different walk

Multi-graph memory takes the same instinct further. The same memory item appears on several orthogonal views at once — semantic, temporal, causal, entity — and the query picks a traversal policy based on intent. A question about concepts walks the semantic view. A question about when walks the temporal one. A question about why walks the causal one.

The concrete case is worth holding onto. To work out why a deploy was rolled back, the agent starts from the event in time, follows the causal edge to a test that failed, and only then collects the entities involved. Plain similarity would have returned documents about deployments: the right topic, the wrong shape of answer. That is the decision this touches. A single store entangles time, cause and identity, and gives you plausible neighbours with no chain between them. Separating representation from retrieval logic keeps the reasoning path inspectable, and what you are willing to leave an agent alone with depends far more on being able to see how it got somewhere than on whether it got there. The failure to avoid is building four views and no policy that decides which one a given question needs. Then you pay for all of them and use one.

There is an incremental version of this and a full one, and you do not have to start with the full one. Adding concepts and facts to a retrieval system you already run keeps the simplicity of similarity search and buys structure only where relations are actually load bearing. What both versions insist on is the repair step. When an answer comes back wrong, the fix is the fact and the edge that produced it, not the embedding. Re-embedding a wrong fact only files the mistake more neatly.

None of this lives in the model. The model reads what it is handed; the shape of the store decides what could have been handed to it, and which questions are answerable at all. Two weeks from now the fact will still be sitting there, correctly spelled and easy to find. Whether it is worth anything depends on what it is still attached to.