Can agents reconstruct memory on demand instead of retrieving it?

Most memory-augmented agents run a rigid pipeline: retrieve a fixed set of memories by similarity, then reason over them. MRAgent's claim is that this ordering is the bug. Because the retrieval step is committed before the model has seen any intermediate evidence, the agent cannot adapt what it looks up based on what it discovers mid-inference. The fix is to interleave reasoning directly into memory access over an associative Cue–Tag–Content graph, so retrieval becomes an active, multi-step reconstruction — the agent iteratively explores and prunes traversal paths conditioned on accumulated evidence, which yields up to 23% gains on LOCOMO and LONG-MEMEVAL while cutting token and runtime cost.

The titular framing — memory is reconstructed, not retrieved — is a genuine reframing borrowed from human cognition, where recall is a constructive act rather than a lookup. The deeper architectural move is deferring relational reasoning to the retrieval stage: instead of pre-computing all relational structure into the graph (the knowledge-graph instinct), MRAgent keeps construction simple and resolves complex dependencies on demand through targeted, state-dependent exploration. This is the traversal-side complement to Should agent memory adapt dynamically based on execution feedback? and to Is agent memory a storage problem or a connectivity problem? — both locate memory's value in dynamic access over a connected structure rather than in the store itself. It also operationalizes Can agents fail from weak memory control rather than missing knowledge?: the failure was control over access, and active reconstruction is that control.

The cost is the mirror image of the benefit, and the paper is candid about it. Because relational reasoning is deferred to retrieval, reconstruction cost grows with exploration depth — queries needing many traversal hops incur higher latency than single-shot retrieval. So the win is not unconditional: active reconstruction pays off when relational structure is sparse and query-specific, but a query that must traverse deeply can cost more than just dumping a large retrieved context would have. The pruning mechanism is doing the real work of keeping this from exploding combinatorially.