Verbatim Storage vs. Fact Extraction vs. Knowledge Graphs: Three Memory Architectures, One Test
Three architecture families account for most production agent-memory systems as of 2026: verbatim or archival storage, which keeps retrieved content close to the form it arrived in; fact extraction, which processes raw content into a smaller set of discrete statements before storing it; and temporal knowledge graphs, which represent content as entities and time-stamped relationship edges. "Agent memory" as a category name hides how differently these three behave — each preserves a different kind of structure and discards the rest, and the retrieval unit each one returns (a whole passage, a single fact, or one graph edge) is a first-order design choice, not an implementation detail. DecisionSynth Bench runs exactly this comparison as a concrete test: the same decision-recall task set, evaluated against systems built on each of the three architectures, over the same corpus.
The two options
Verbatim / Archival Storage
Stores retrieved content close to verbatim rather than processing it into a smaller representation first. No extraction step means no extraction loss — but also none of the scale benefits compression buys.
- Highest fidelity floor of the three — on DecisionSynth Bench's held-out scoreboard, an archival system scores 0.917–0.922 overall exact-match, within a few points of the 0.980 deterministic no-LLM baseline
- Creator-model-invariant: because nothing is extracted, the choice of which LLM sits in the pipeline barely moves the score (0.922 vs. 0.917 across two different creator models) — a property none of the compressed architectures share
- Simplest mental model to reason about and audit: what goes in is close to what can come back out, with no separate extraction step whose behavior has to be independently verified
- Doesn't scale storage or retrieval cost the way a compressed representation does — the same property that keeps fidelity high is a cost tradeoff at real production corpus sizes, not a free win
- Weakest of the three at cross-record aggregation tasks specifically — nothing about verbatim storage organizes relationships between records, so a question needing several records connected (which past cases match this one) scores lower than single-record recall on the same system
- The retrieval unit — a whole passage — can be coarser than a question needs, returning more context than is relevant even when the relevant fact is present somewhere inside it
Choose verbatim or archival storage when the corpus stays small enough that keeping everything close to verbatim remains practical, and near-complete fidelity matters more than the storage and retrieval efficiency a compressed representation would buy.
Compressed Representations: Fact Extraction and Knowledge Graphs
Both process raw content into a smaller stored representation before keeping it — extraction pulls out discrete facts, graphing builds entities and time-stamped relationship edges. Both trade fidelity for scale, and each loses a different kind of structure in the process.
- This is the entire design point of both: neither has to keep every raw record queryable forever, which is what lets a memory system scale past a verbatim system's storage and retrieval cost
- Fact extraction's retrieval unit — a discrete statement — is precisely on-target when a question needs exactly one fact, without the surrounding context a whole passage would carry along
- A temporal graph's retrieval unit — an edge with an explicit validity window — is built-in structure a passage or a fact doesn't have, which is why a graph-based system posts the best temporal-ordering exact-match of any LLM-backed architecture on DecisionSynth Bench's held-out set (0.886, ahead of the archival system's 0.760) even while trailing badly overall
- Extraction can silently drop the connective reasoning between facts — a pipeline can preserve 'the client chose option B' while discarding the override reason behind it, because a salience filter tuned toward headline facts tends to rank the reasoning as secondary
- Extraction quality is a property of the pipeline, not purely of the underlying model — the same LLM extracted roughly 18 edge facts per episode under one configuration and roughly 2.8 under another, a difference driven by the extraction prompt and context window, not model capability
- A graph's fine-grained retrieval unit can work against it on questions needing a complete record: a single decision can shred into roughly 25 individual edges, and a fixed retrieval budget spent across them can crowd out a full picture of any one record, which is exactly why the same system that wins temporal ordering can score far lower on exact-identifier recall
- Both architectures swing with the choice of creator or extraction model in ways verbatim storage structurally cannot, since there's no extraction step for a model choice to shape in the first place
Choose fact extraction when individual-fact recall matters most and the extraction pipeline is verified to preserve the specific structure your use case needs (a rationale, a citation) rather than just the headline outcome. Choose a temporal knowledge graph when ordering or change-over-time is the primary question, and route exact-identifier lookups through a different, complementary path.
Decision framework
The question that actually decides between these three is: what is the atomic unit your system needs to return when it answers a question, and does that unit's grain match the grain of the question being asked? A passage over-returns — it carries more context than most questions need, at the benefit of rarely missing something entirely. A fact under-connects — it's precise about one thing and silent about how that thing relates to anything else. An edge over-fragments a single record while making order and change over time a first-class, retrievable property instead of something to reconstruct indirectly from timestamps buried in text.
No architecture is a strict upper bound on the other two. A verbatim system's near-ceiling score reflects that it has discarded the least, not that discarding is always wrong — production systems compress by design because storing everything verbatim forever doesn't scale, and DecisionSynth Bench's numbers show exactly what that compression costs on this corpus, task type by task type.
One factor cuts across the choice of architecture entirely: which model sits inside the extraction or graphing pipeline. The same underlying LLM has been shown to extract very different amounts of structure — and in different directions — depending on the pipeline it's embedded in, which means an architecture decision and a model decision are not independent choices to be made separately; a benchmark score that reports only one creating model per architecture is hiding a variable as large as the architecture choice itself.
Bottom line
There's no universally best architecture among verbatim storage, fact extraction, and knowledge graphs — there's a fidelity-vs-scale tradeoff with verbatim storage at one end, and among the two compressed approaches, extraction and graphing preserve genuinely different structure rather than one simply being a better version of the other. The right choice follows from the retrieval unit your hardest real question needs, verified empirically against a task set that actually exercises it — not assumed from the architecture's reputation.
FAQ
Is a knowledge graph strictly more advanced than fact extraction?+
No — they're different tradeoffs, not a hierarchy. A graph's edge-level retrieval unit is a better fit for ordering and change-over-time questions specifically; a flatter fact-extraction unit can be a better fit when a question needs one precise statement without graph-traversal overhead. Neither dominates the other across all task types.
Can a system combine more than one of these architectures?+
Architecturally, nothing prevents it — a system could keep a verbatim archival tier for high-fidelity lookups alongside an extracted or graphed index for scale-sensitive retrieval, routing a query to whichever tier fits it. Whether a specific vendor product actually does this, and how well, is a question to verify directly against that product rather than assume.
How is this comparison actually tested, rather than argued from first principles?+
DecisionSynth Bench runs all three architectures (via a Letta archival adapter, a Mem0 extraction adapter, and a Zep/Graphiti temporal-graph adapter) against the same 543 held-out decision episodes, at a matched retrieval budget, scored on identical task types. The architectural properties described above are drawn from each project's own published design and illustrated with those scoreboard results — not asserted without a concrete run behind them.
Does the choice of extraction model matter more or less than the choice of architecture?+
Both matter, and they interact rather than being separable. Verbatim storage barely moves with model choice because there's nothing for a model to extract. The two compressed architectures each swing meaningfully with which model does the extracting — and in opposite directions from each other on the same corpus — which is why a scoreboard row is more accurately read as pipeline × model than as architecture alone.