Is agent memory a storage problem or a connectivity problem?

Most memory-augmented agents treat memory as a repository: store trajectories, retrieve by similarity. FluxMem reformulates the problem. For a long-horizon agent, memory effectiveness ultimately depends on whether the most useful memories can be accessed at each decision step — and that accessibility is a property of connectivity, not of storage. The paper formalizes usefulness as a connectivity problem and models memory as a heterogeneous graph across semantic, episodic, and procedural layers, where context is an activated subgraph rather than a retrieved list.

The cognitive grounding is precise. Drawing from how human memory works, the operative claim is that memory is the long-term sedimentation of units and their connections. Operations split across two levels: at the unit level the system creates new units and reshapes existing ones; at the connection level it establishes links between co-activated units to form functional associations and prunes links that prove irrelevant. The associative network — what is linked to what — determines whether a query lands on the useful neighborhood. Storage is necessary but inert; the links are what make a stored memory reachable in context.

This reframes where the engineering effort should go. If usefulness is connectivity, then better embeddings or larger stores have diminishing returns — the lever is the topology that decides co-activation. It complements rather than contradicts the vault's existing memory taxonomies: since Can three axes replace the short-term long-term memory split?, FluxMem's contribution sits on the dynamics axis, specifying that the evolution operator acts on connections, not just units. It also reframes the failure diagnosis — since Does agent memory degrade when continuously consolidated?, consolidation hurts when it strips applicability conditions; on the connectivity view, that is a link failure (wrong or missing associations), suggesting topology repair as the fix. Counterpoint: graph connectivity adds retrieval-time traversal cost and a topology to maintain, so the connectivity frame trades storage simplicity for structural overhead. Why it matters: it tells builders the binding question is "what is linked to what," not "what is stored."