A comparison, not a verdict.
A retrieval step ranks a store of passages against a query and returns whatever scores closest. The ranking runs fresh each time, which means a passage from days earlier can outscore one from an hour ago if the wording happens to be closer, even after the older passage has since been superseded. Similarity is a proxy for relevance, not a record of it.
The phrase reasons on versus retrieves from is often used to describe the alternative: a model working over a structured graph rather than a ranked list of passages. Taken literally, the phrase overstates the difference, since both a graph and a retrieval store are read into a context window before any reasoning happens. The comparison that survives closer inspection is narrower: what happens to a decision once it turns out to be wrong, and how many writers a store can absorb at once. That comparison is easiest to see against a concrete example, with the four primitives of substrate memory as one side of it.
What happens to a wrong decision.
Two categories of store diverge sharply once a decision needs to be revised. The distinction is easiest to see traced against a concrete example: Letta, an open-source agent framework whose agents share memory through blocks pinned directly into each agent's context window.
| Property | What happens |
|---|---|
| overwrite vs. supersede | A shared memory block in a framework such as Letta is mutated in place: an update call replaces the block's content, and the earlier text is gone. A typed graph instead files a correction as a new entry linked to the one it replaces, and the earlier entry stays in the record, dated and attributed. One structure can answer what was decided before the change and why; a structure that overwrites cannot, because the earlier text no longer exists to ask about. |
| concurrent writers | A flat block shared by several agents is a small-scale primitive: simultaneous updates from more than a couple of writers can overwrite one another, which is why frameworks built around this pattern generally recommend partitioning the block by writer or timestamp to avoid collisions. An append-only graph, where each write adds a new linked entry rather than mutating shared state, does not share that collision surface and holds up as the number of concurrent writers grows. |
| the size limit | A block pinned into every attached agent's context window is bounded by that window; once it fills, the usual remedy is to summarize or archive older content, a smaller version of the same compaction problem memory systems exist to solve. A graph that is queried rather than pinned does not have to fit inside one context window, because only the relevant slice is read back for a given query. |
When the record gets written.
A second distinction sits earlier in the pipeline, before any query happens at all: when the record of a decision gets written, and by which process. Many memory systems separate the two. One process does the primary work; a second process, often a summarizer or a periodic review pass, decides afterward what from that work is worth keeping. That second process is reconstructing importance from a transcript it was not present for.
An architecture where the same act that makes a decision also files it collapses those two steps into one. The process that had the context is the one that decides what mattered, at the moment it mattered, rather than a separate pass inferring it later from the outside. This is a claim about when a memory gets written and by whom, not about how it is read back afterward.
What the record keeps.
A process that filters after the fact tends to lose the same categories of information, regardless of how good the filter is:
- Dead ends. A path the reasoning tried and abandoned is data about what did not work, and a summary written for what did work has no reason to keep it.
- Backtracks. When a decision is reversed, the correction carries information about why the earlier version was wrong; a filter built to record outcomes rather than reversals drops it.
- The surrounding context. The reasoning that produced a decision often depends on details that look irrelevant once the decision is made, so a filter built to keep answers strips the details a later reader would need to evaluate the answer.
- Future questions. A filter decides what is worth keeping based on what looks important now; it cannot anticipate which detail a later, differently scoped question will need.
- The reasoning chain itself. In many cases the record with lasting value is not the conclusion but the chain that produced it, and a summary that keeps only the conclusion discards the part with the most value.
A structure that records reasoning as it happens is less likely to lose any of the five, because there is no later filtering step to lose them at.
Where the line actually is.
The phrase this page is titled after should not be read as a claim about where reasoning happens mechanically. Both a graph and a retrieval store are read into the same kind of context window before a model reasons over either one; there is no version of either architecture where a model reasons on data without that data first being loaded into context. A framing that implies otherwise does not hold up.
The distinctions that do hold up are the ones traceable through one full read, reason, and write cycle: what the store's schema records, what happens to a wrong entry, and how many writers it can absorb at once. Tracing a memory claim this way, rather than checking whether the language sounds different, is a reasonable general test for any comparison between memory systems, including the ones on this page.
Common questions.
Does a model literally reason on the graph instead of retrieving from it?
Not in a mechanical sense. A query against a graph still returns a slice of data that is loaded into the model's context window before reasoning happens, the same basic step a retrieval system uses. The differences that hold up are in what the store records about a decision's history and how many writers it can absorb, not in the read step itself.
Isn't a typed graph just a retrieval system with extra structure?
Structurally, a graph can be queried in a way that resembles retrieval. What differs is what the schema is built to represent: typed links such as supersedes or answers between entries, rather than only similarity between passages. A query against that structure returns relationships the store recorded on write, not relationships inferred at query time from wording alone.
What happens when a decision in the graph turns out to be wrong?
A new entry is written and linked to the one it corrects; the earlier entry is not deleted or edited in place. The record keeps both the original decision and its correction, which a store that overwrites its own content in place cannot do.