Agent memory has two distinct failure points: deciding what's worth storing from experience, and finding the right thing when needed.

This explores why "extraction" and "retrieval" name two genuinely different jobs in agent memory, even though both sound like "getting the right thing." The cleanest framing comes from work arguing that agent memory should be evaluated as a data-management system, decomposed into storage, extraction, retrieval, and maintenance stages How should we actually evaluate agent memory systems?. Extraction happens on the *way in*: as raw interaction history streams past, something has to decide what's worth keeping and in what shape. Retrieval happens on the *way out*: given a current decision, something has to surface the relevant stored unit. Bundling them together hides which one actually broke — a task can fail because the useful fact was never extracted, or because it was stored but couldn't be found.

Extraction is fundamentally a compression-and-shaping problem. Autonomous memory folding, for instance, consolidates interaction history into episodic, working, and tool schemas so the agent isn't drowning in verbatim logs Can agents compress their own memory without losing critical details? — the hard part is discarding detail without discarding what later turns out to matter. This is also where granularity decisions live: whether to extract memory at the workflow level, as causal rules, or as fine-grained state-action pairs depends entirely on the task domain Does agent memory work better at one level of abstraction?, and agent working memory splits further into dialogue-level and turn-level components that each demand different extraction and update policies How should agent memory split across time scales?. Extraction, in other words, is where you commit to an abstraction — and you're stuck with it downstream.

Retrieval is where a subtler insight shows up: what you stored matters less than whether you can *reach* it. One line of work argues memory effectiveness is really a connectivity problem — usefulness depends on the links between co-activated units forming a reachable subgraph, not on the raw store, which is "necessary but inert" Is agent memory a storage problem or a connectivity problem?. That reframes retrieval away from fixed similarity lookup toward topology: memory that continuously creates and prunes links from execution feedback beats static retrieval Should agent memory adapt dynamically based on execution feedback?. Pushed further, retrieval stops being a lookup at all and becomes *reconstruction* — interleaving reasoning with active graph traversal, pruning paths as evidence accumulates, outperforms retrieve-then-reason pipelines Can agents reconstruct memory on demand instead of retrieving it?.

The thing you didn't know you wanted to know: the two stages can be governed by completely different control regimes. Memory management splits into an explicit "hot path" where the agent decides via tool calls, and an implicit background path triggered programmatically — and extraction versus retrieval can each sit on either path, trading context-sensitivity against reliability How should agents decide what memories to keep?. That separation is also what lets some systems learn continuously by operating *entirely* through memory operations — reformulating adaptation as extraction and retrieval over an experience store instead of weight updates Can agents learn continuously from experience without updating weights?. Seen this way, extraction and retrieval aren't two names for one skill; they're the two ends of a pipeline where getting one right can't rescue getting the other wrong.