Executable Memory Evolution Graphs

• Executable Memory Evolution Graphs are a set of formalisms that represent memory as an evolving computational substrate rather than static data.
• They couple addressable semantic nodes with deterministic update rules to enable runtime execution, planning, and state verification.
• These models improve efficiency and robustness in dynamic environments, with applications ranging from compiler optimization to GUI automation.

Searching arXiv for papers and the specific works associated with “Executable Memory Evolution Graphs.” Executable Memory Evolution Graphs (EMEGs) denote a family of formalisms in which memory is represented not as passive retrieved text but as an executable, evolving graph whose nodes, edges, or patches participate directly in computation, planning, verification, or runtime adaptation. Across recent arXiv literature, the term spans several technical instantiations: a deterministic addressable semantic substrate with bounded local evolution and an invariant compute envelope (Martin, 17 Feb 2026); a population-level evolution graph over compiler-valid memory mappings for accelerator placement (Khadka et al., 2020); executable knowledge graphs for GUI planning (Qin et al., 12 May 2026); versioned typed-code user memory (Li, 15 Jun 2026); query-time memory-chain evolution for LLM agents (Xu et al., 14 Jan 2026); patch-based memory histories for dynamic environments (Xu et al., 11 Jun 2026); and graph-organized memory models for verification and runtime systems (Ročkai et al., 2017). The shared idea is that memory evolution is made explicit in graph form and coupled to executable semantics, so that updates, traversals, rule applications, or mutations can be analyzed as structured state transitions rather than as opaque retrieval events.

1. Conceptual scope and defining characteristics

The broadest common feature of EMEGs is that memory is treated as a persistent computational substrate rather than as a bag of retrieved facts. In the deterministic semantic-state formulation, the executable memory evolution graph is the addressable graph $G=(V,E,A)$, where $V$ is the node set, $E$ the bounded local relational structure, and $A: ID \to NodeRecord$ an addressability mapping from stable identifiers to node records (Martin, 17 Feb 2026). In GUI automation, the corresponding structure is a directed graph $G=(S,A,E)$ with alternating state and action nodes, where paths encode runnable routines and transitions are deterministic in the graph (Qin et al., 12 May 2026). In User as Code, the same idea is recast as a provenance-rich directed acyclic graph over fact nodes, checkpoint state nodes, code version nodes, and alert nodes generated by deterministic rule execution (Li, 15 Jun 2026).

The literature therefore uses the term across at least three levels of abstraction. At the substrate level, the graph is the memory itself and local operators directly mutate stored semantic state (Martin, 17 Feb 2026). At the planning level, the graph encodes executable transitions over environment states, actions, or views, and execution consists of selecting and traversing valid paths (Qin et al., 12 May 2026, Ge et al., 2 Jun 2026). At the governance or versioning level, the graph records how artifacts, patches, or typed snapshots evolve over time under validation, rollback, or deterministic recomputation (Xu et al., 11 Jun 2026, Garralda-Barrio, 26 May 2026, Li, 15 Jun 2026).

A recurring contrast is with retrieval-centric or inference-driven architectures. Several works explicitly oppose executable memory to regimes in which semantic continuity must be reconstructed at query time. The deterministic substrate paper states that contemporary inference-driven AI architectures reconstruct semantic state through probabilistic recomposition, whereas its substrate stores semantic continuity as persistent, addressable structure evolved under a bounded local operator $g(t)$ (Martin, 17 Feb 2026). User as Code similarly argues that storing a fact and acting on it are separate steps in bag-of-facts systems, while executable memory unifies representation and reasoning in ordinary Python functions over typed state (Li, 15 Jun 2026). Chain-of-Memory reaches a related conclusion from the opposite design direction: instead of building a heavy persistent graph upfront, it dynamically evolves executable inference paths at query time to bridge the recall–reasoning gap (Xu et al., 14 Jan 2026).

2. Formal models of graph-based executable memory

A prominent formalization appears in the semantic substrate model, where the persistent semantic substrate is a graph-structured state space $$\Sigma \subset \mathcal{H} = \ell_2(V)\otimes \mathbb{R}^d$$, with node states $\psi_i \in \mathcal{H}$ representing bounded semantic units, and state evolution governed by bounded local generators composing a time-modulated operator $g(t): \Sigma \to \Sigma$ (Martin, 17 Feb 2026). Locality is expressed as $\Delta s(t)_i \subset N_k(i)$, operator norms satisfy $V$0, and the state update rule is instantiated as

$V$1

Within this formulation, the key bounded-work constraint is

$V$2

where $V$3 is total memory cardinality (Martin, 17 Feb 2026).

In Executable Agentic Memory, the graph formalism is environment-specific. States $V$4 are GUI pages or screens, actions $V$5 are executable operations or mined action groups, and edges $V$6 encode action availability and deterministic transitions (Qin et al., 12 May 2026). Planning induces a deterministic finite-horizon MDP whose transitions $V$7 follow graph edges, while MCTS uses

$V$8

for search over graph actions (Qin et al., 12 May 2026). The graph is executable because paths correspond to discovered and verified UI transitions that are later run on-device.

User as Code provides a versioned memory graph grounded in an append-only log

$V$9

and checkpointing operator

$E$0

where $E$1 is a typed Python state snapshot and $E$2 includes schemas and persistent constraints (Li, 15 Jun 2026). Deterministic rule execution is modeled as

$E$3

so alerts and derived state become first-class graph outputs rather than downstream query results (Li, 15 Jun 2026).

EvoMem introduces a patch-based formulation for dynamic environments. A patch is

$E$4

with before-state, after-state, rationale, semantic summary, and evidence; memory evolves by composition,

$E$5

and the corresponding evolution graph has state-level edges $E$6 or finer-grained fact-level transformations (Xu et al., 11 Jun 2026). This explicitly supports rollback, version-aware reasoning, and conflict detection.

Two older graph-memory lines broaden the concept. DiVM models executable memory as graph-organised memory for LLVM-based programs, with objects as nodes, pointer relations as labeled edges, and a machine state $E$7 evolving through instruction-level transitions (Ročkai et al., 2017). The mass-based memory model treats memory as a dynamic edge-weighted graph $E$8, with node masses and edge weights updated phase by phase under environmental inputs (Mollakazemiha et al., 2023). Although these works do not target agent memory in the recent sense, they supply formal precedents for executable graph-state evolution.

3. Operational semantics and execution regimes

In substrate-oriented EMEGs, execution consists of localized traversal and mutation. The deterministic C++ engine exposes operations such as Insert(node), Connect(u,v,w), Traverse(seed, radius k, predicate P), Evolve(\Delta s_t), Update(node,\delta\psi), Delete(node/edge), and Compact/GC() (Martin, 17 Feb 2026). Traversal is adjacency-bounded and excludes global scans, ANN search, or transformer invocations during traversal. Determinism is attributed to purely local operators with no stochastic steps, the absence of global recomputation or ANN search, and stable addressability (Martin, 17 Feb 2026).

In query-time EMEGs, execution is the construction of an inference path. Chain-of-Memory starts from a flat store of turn-level memory nodes $E$9, retrieves a candidate pool $A: ID \to NodeRecord$0, initializes anchor chains, and iteratively expands each chain with the state-aware gating score

$A: ID \to NodeRecord$1

Expansion terminates when the best candidate exhibits a cliff-like drop under the adaptive truncation rule $A: ID \to NodeRecord$2 (Xu et al., 14 Jan 2026). Execution then means serializing the selected chain as structured context for the LLM.

In environment-graph EMEGs, execution directly changes external state. GUI EAM alternates between the live UI and its knowledge graph: it retrieves a path with Q-guided MCTS, validates and parameterizes the plan, executes actions using a local executor, and matches each observed screen to the intended successor via dual-layer deduplication (Qin et al., 12 May 2026). EvoMemNav uses a Visual-Semantic Memory Graph

$A: ID \to NodeRecord$3

with room, view, and object nodes plus navigability and visibility edges, and runs a budgeted coarse-to-fine controller that selects anchors or frontiers and then performs structured Stop verification (Ge et al., 2 Jun 2026).

In governed runtime systems, execution is a lifecycle transition over persistent capabilities. Governed evolution of agent runtimes formalizes operational memory state as $A: ID \to NodeRecord$4 and writes governed transitions

$A: ID \to NodeRecord$5

where $A: ID \to NodeRecord$6 is a HarnessMutation operator, $A: ID \to NodeRecord$7 a governance policy, and $A: ID \to NodeRecord$8 a validation predicate (Garralda-Barrio, 26 May 2026). The same paper casts the entire runtime as a labeled transition system over states $A: ID \to NodeRecord$9 and labels such as create, validate, promote, mutate, deprecate, rollback, and compose (Garralda-Barrio, 26 May 2026).

4. Representative architectures and design patterns

The major EMEG variants can be organized by what is made executable: semantic state, paths, patches, mappings, or runtime artifacts.

Variant	Core graph unit	Execution semantics
Deterministic semantic substrate	Addressable semantic nodes and local neighborhoods	Bounded-local traversal and mutation under $G=(S,A,E)$0
GUI agent memory	State-action-state transitions	Retrieval-and-execution of verified plans
User memory as code	Fact, checkpoint, code, and alert nodes	Deterministic rule execution over typed state
Query-time memory chains	Retrieved fragments linked online	Greedy chain growth and truncation for inference
Patch-based dynamic memory	Versioned update patches	Reconstruct, augment, or roll back state by patch application
Runtime governance graph	Validated artifacts and lifecycle edges	Governed promotion, mutation, deprecation, rollback
Memory-mapping evolution	Compiler-valid memory layouts	Evolutionary mutation/crossover plus hardware execution

The deterministic semantic substrate emphasizes locality, stable addressability, and persistent embeddings. Nodes store $G=(S,A,E)$1 with $G=(S,A,E)$2 in measurements, edges are adjacency lists with $G=(S,A,E)$3 edges per node, and direct addressability replaces similarity indices (Martin, 17 Feb 2026). This suggests a design centered on structural continuity rather than semantic reconstruction.

Executable Agentic Memory emphasizes graph construction and compression. New trajectories are merged by

$G=(S,A,E)$4

states are deduplicated by coarse embedding retrieval plus fine VLM verification, and frequent action pairs are merged BPE-style using

$G=(S,A,E)$5

followed by creation of high-level action-group nodes (Qin et al., 12 May 2026). The graph therefore evolves not only by accumulation but by semantic compression.

User as Code separates memorization and structuring. Facts are never deleted or overwritten in Phase 1, while Phase 2 periodically regenerates typed Python dataclasses from the full fact corpus, with out-of-schema material stored in notes: list[str] (Li, 15 Jun 2026). This produces a graph in which provenance, versioning, and deterministic checks are explicit. A plausible implication is that this design makes contradiction handling a graph update problem rather than a retrieval-ranking problem.

Chain-of-Memory offers a different pattern: lightweight construction paired with sophisticated utilization. The graph is implicit and query-conditioned, with edges weighted online by relevance and chain coherence rather than stored offline (Xu et al., 14 Jan 2026). This distinguishes it from persistent graph-heavy systems and suggests that EMEGs need not always be durable object stores; they can also be transient executable structures assembled at inference.

EvoMemNav and VehicleMemBench extend the idea to embodied and multi-user environments. EvoMemNav stores raw views as first-class nodes in a room–view–object hierarchy and updates graph-attached priors through reflection-driven write-back after each subtask (Ge et al., 2 Jun 2026). VehicleMemBench models histories as coupled memory and environment strata, with memory checkpoints, user preference nodes, retrieval edges, tool edges, and comparator edges that align predicted and reference end states (Chen et al., 25 Mar 2026). In both cases, the graph is executable because it drives action selection under explicit environment dynamics.

5. Empirical findings and benchmarked behavior

The strongest empirical claim for substrate-level EMEGs is the ICE-AGE regime reported for the deterministic semantic substrate. On Apple M2-class silicon, across the 1M–25M node envelope, traversal latency was approximately $G=(S,A,E)$6–$G=(S,A,E)$7 ms, CPU utilization was approximately $G=(S,A,E)$8 baseline with $G=(S,A,E)$9–$g(t)$0, and thermal behavior showed no scale-correlated ramp after residency stabilization (Martin, 17 Feb 2026). The paper summarizes this as an invariant compute envelope in which

$g(t)$1

within the tested regime (Martin, 17 Feb 2026). Measured node density was approximately $g(t)$2–$g(t)$3 KB/node in the Float64 baseline and approximately $g(t)$4 B/node in the Float32 compressed regime, yielding a capacity projection of approximately $g(t)$5 nodes per TiB under binary accounting (Martin, 17 Feb 2026).

In memory-placement optimization, the EGRL framework treats executable memory mappings as nodes in an implicit evolution graph over compiler-valid layouts. It was trained and validated directly on Intel NNP-I and achieved 28–78\% speed-up compared to the native NNP-I compiler on BERT, ResNet-101, and ResNet-50 (Khadka et al., 2020). Reported workload-level results were 1.28× speedup on ResNet-50, 1.78× on ResNet-101, and 1.66× on BERT, with EGRL outperforming EA, Greedy-DP, and PG baselines on these workloads (Khadka et al., 2020). Here, executability is defined by compiler acceptance and hardware measurement rather than by symbolic path validity.

In GUI automation, EAM reports success-rate gains over model-centric baselines. On AndroidWorld, MobileMiniWob++, and DroidTask, EAM achieves 52.6, 76.1, and 86.1 success rate respectively, exceeding UI-TARS-7B by 19.6, 22.8, and 31.1 points, with average latency 2.8 s/step and token cost 8.3K/step, approximately 6× lower than GPT-4o at 50.8K (Qin et al., 12 May 2026). These numbers are attributed to retrieval-and-execution planning over the knowledge graph, action-group compression, and Q-guided MCTS (Qin et al., 12 May 2026).

For executable typed-code memory, User as Code matches strong recall baselines while diverging sharply on aggregation and proactive checking. It reports 78.8\% on LOCOMO, 99.0\% on analytical inference, and Active Service performance of 100\% on 40 standard scenarios and 85\% on 20 hard scenarios; without precomputed alerts, UaC drops to 52.5\% on Active Service (Li, 15 Jun 2026). The same paper states that retrieval-based memory collapses to 6–43\% on aggregate questions, while UaC stays near-perfect because answers are computed over typed state rather than retrieved from top-$g(t)$6 text (Li, 15 Jun 2026).

Dynamic-environment evaluation strengthens the case for explicit memory evolution. EvoArena reports that current agents achieve an average accuracy of 39.6\% across evolving terminal, software, and social domains, while EvoMem yields an average gain of 1.5\%, a chain-level gain of 3.7\%, and improves GAIA and LoCoMo by 6.1\% and 4.8\% (Xu et al., 11 Jun 2026). VehicleMemBench complements this with an executable in-vehicle simulator, where success is evaluated by exact state match and field/value F1 rather than by LLM or human judging; histories contain on average 81.78 events per instance and approximately 92,819 tokens (Chen et al., 25 Mar 2026). These results suggest that EMEGs become especially relevant when the target problem includes evolving constraints, stateful execution, or long-horizon accumulation.

6. Comparative interpretation, limitations, and research directions

A consistent theme in this literature is that executable memory is introduced to address failure modes of static retrieval or latent recomposition. Deterministic semantic graphs remove ANN search, context reinjection, transformer passes for traversal, and query-time re-embedding, so work scales with local semantic change $g(t)$7 rather than with total memory $g(t)$8 (Martin, 17 Feb 2026). User as Code avoids top-$g(t)$9 enumeration failure on aggregates by making typed computation and constraint execution first-class (Li, 15 Jun 2026). EAM reduces long-horizon GUI fragility by replacing repeated free-form generation with planning over a verified state machine (Qin et al., 12 May 2026). EvoMem prevents state collapse in evolving environments by retaining before/after patch structure and evidence, rather than only the latest snapshot (Xu et al., 11 Jun 2026).

At the same time, the papers identify clear applicability conditions. The ICE-AGE invariance claim requires bounded degree distribution, updates confined to finite $$\Sigma \subset \mathcal{H} = \ell_2(V)\otimes \mathbb{R}^d$$0, absence of adversarial densification or global rewrites, and stable memory residency with cache-fitting working sets (Martin, 17 Feb 2026). EAM notes limitations in robust incremental evolution under app updates, with UI drift, stale transitions, and state aliasing identified as failure modes (Qin et al., 12 May 2026). User as Code highlights scaling limits of full-corpus regeneration, with inputs capped at approximately 500K characters and a need for hierarchical structuring beyond approximately 100 sessions (Li, 15 Jun 2026). EvoMem emphasizes precondition failures, overlapping patch scopes, and retrieval errors over patch histories as sources of conflict (Xu et al., 11 Jun 2026).

There is also no single canonical EMEG architecture. Some systems favor strong persistence and deterministic execution, as in addressable semantic substrates and typed Python state (Martin, 17 Feb 2026, Li, 15 Jun 2026). Others favor lightweight or transient structures, as in Chain-of-Memory’s query-conditioned paths (Xu et al., 14 Jan 2026). Some center executability in the external environment, as in GUI and navigation systems (Qin et al., 12 May 2026, Ge et al., 2 Jun 2026), while others center it in internal runtime governance or software verification (Garralda-Barrio, 26 May 2026, Ročkai et al., 2017). This suggests that “Executable Memory Evolution Graphs” functions less as a single architecture than as a unifying research program: memory is graph-structured, its evolution is explicitly represented, and the representation participates directly in execution, validation, or controlled state change.

Future directions stated across the papers converge on scale, distribution, and stronger correctness guarantees. The deterministic semantic substrate identifies billion-node runtime validation, tail-latency studies, adversarial densification stress, NUMA and distributed substrate design, and Joule-level energy instrumentation as future work (Martin, 17 Feb 2026). EAM calls for dynamic graph updates, principled online pruning and aging, transfer across apps, and hierarchical planning atop action groups (Qin et al., 12 May 2026). User as Code points to hierarchical or incremental checkpointing, learned constraint generation, additive retrieval layers, and richer typed invariants (Li, 15 Jun 2026). EvoMem proposes richer patch semantics, learned patch generators, probabilistic patches, causal dependencies, and execution-aware retrieval over the minimal executable prefix (Xu et al., 11 Jun 2026). Taken together, these directions indicate a continuing shift from memory as retrieved evidence toward memory as a versioned, executable, and inspectable state space.