Substrate memory vs. vector memory and RAG

Vector search does one job well: given a query, return the passages that resemble it most closely. For recency-weighted lookups and loosely structured corpora, that is often enough, which is why retrieval-augmented generation over a vector store is the default memory layer for most language-model applications built in 2026.

Graph-structured memory has also stopped being a novelty. A 2026 industry survey (Mem0's State of Memory report) counted graph-memory integrations across thirteen separate agent frameworks — evidence that “the memory is a graph” is no longer a distinguishing claim on its own. A comparison that starts by asserting graph memory as new is starting from a false premise.

The comparison worth having is not whether a graph beats a vector index in the abstract. Both structures are used inside Vinculum's own substrate memory, described further below. The comparison worth having is how the graph gets built, and what it ends up recording once it exists.

Where graph-structured retrieval has been benchmarked directly against vector-only retrieval, the graph side wins on a specific, well-documented class of query: multi-hop reasoning, where the answer depends on chaining facts spread across more than one document. On the MultiHopRAG benchmark, a graph-based retrieval pipeline has been reported to improve recall by 11 percentage points over a strong vector-only baseline.

That gain has a cost. Building the graph that retrieval runs against requires an extraction pass: a model reads the corpus and proposes entities and relations, which are then assembled into a knowledge graph before any query can be answered. Microsoft's GraphRAG project, which popularized this pipeline, runs an extraction-and-indexing pass many times more expensive than a comparable vector-embedding pass — commonly cited at 20 to 100 times the cost, tens to hundreds of dollars for a typical corpus.

Both figures describe graph-versus-vector retrieval in general, not a comparison against Vinculum specifically. They are the terms the field itself is already debating: better multi-hop recall, at a real and quantified indexing premium.

That indexing premium is not an accident of implementation. It is the cost of extraction: turning an existing pile of unstructured text into a structured graph requires a model to re-read that text and infer entities, relations, and their relative importance, after the fact and without the context the original author had.

Substrate memory names a different write path. Entries are typed and linked by the agent doing the work, as a direct product of that work — a decision recorded as a decision, a reversal recorded as a link to what it replaces — rather than assembled by a separate model reading a transcript afterward. There is no corpus to extract from and no extraction pass to run, because the structure is asserted at write time instead of inferred at index time. The indexing-cost tradeoff the field is measuring does not shrink so much as it does not arise: there is no separate indexing step to price.

This is a claim about authorship, not about retrieval quality on its own. It says nothing about whether a live-authored graph out-benchmarks an extracted one on any particular query; it says the two are produced by different processes, with different costs and different failure modes. An extracted graph is bounded by a model's second-hand read of a document. A live-authored graph is bounded by what the working agent actually decided to write down, a related distinction covered in full under reasoning over memory.

The distinction is not graph versus vector; both structures exist in Vinculum's own substrate. It is between an entity-relation triple, inferred from prose by a model that was not present for the original reasoning, and a typed record of a decision, written by the agent that made it. The causal link between two entries — what caused what — is asserted by the author, not guessed at from co-occurrence in a paragraph, a distinction set out in full under what caused what.

None of the above is an argument against vector search, and Vinculum does not run without one. Semantic relatedness — surfacing an entry that resembles a query in meaning rather than through an explicit typed link — is exactly the job a vector index does well, and Vinculum's own substrate uses pgvector for that job: overlap detection between similar findings, a semantically related rail alongside the typed graph, and idea clustering across a project's history.

The 2026 field consensus, stated across multiple independent surveys, is that hybrid architectures — vector search plus graph structure plus a short-term episodic buffer — now appear in nearly every serious production deployment. Vinculum's own design already sits inside that consensus: a typed, causal graph for what an agent reasons on, and a vector index alongside it for what an agent searches by similarity. The two solve different problems and are not substitutes for each other.

The question this page opened with — similarity or causality — is therefore not a choice between two competing memory systems. It describes two different kinds of edge a memory system can have. A vector index gives a resemblance. A substrate gives the record of what happened and why, with resemblance available inside it as one more property an entry can carry, covered further under GraphRAG.