MemTrace: State-Consistent Memory for Long-Horizon Coding Agents

1 Introduction

• Longer histories strain context budgets while repository changes can invalidate earlier observations, test outcomes, and decisions during multi-stage coding work.After a context refresh, agents must reconstruct completed work, unresolved issues, and which prior evidence still applies.Source: §1 · p. 1
• External-memory systems offload historical information for later retrieval [4] [18] [24], while repository graphs represent files, symbols, and dependencies for code localization [22] [23]; access alone does not determine which historical evidence still supports the resumed task state.Source: §1 · p. 2
• MemTrace stores completed execution as immutable, repository-bound Memory Traces and organizes their dependencies and later verification, correction, or supersession in a Memory Trace Graph.A Repository State Graph represents current files, symbols, tests, and structural relations; shared repository references link the two views.Source: §1 · p. 2
• After context refresh, MemTrace reconstructs the execution frontier, checks candidate evidence against the current repository, filters stale or superseded traces, and restores only evidence needed next.This frames long-horizon coding memory as state alignment rather than history retention alone.Source: §1 · pp. 2–3
• MemTrace consistently outperforms fully evaluated baselines across DeepSWE, SWE-EVO, and SWE-Milestone, while ablations show structured execution memory and repository-state grounding matter.The evaluation covers repository-level engineering, multi-step software evolution, and continuous milestone-based development.Source: §1 · p. 2

Context management for long-horizon agents

• History-management systems compress, mask, retrieve, or organize long trajectories [15] [16] [20] [34], but recovering historical content does not establish that it still supports the task.Trajectory-focused approaches include task- or subtrajectory organization [21] [30] and recoverable history outside active context [12] [19].Source: §2 · p. 3

Agent memory and execution-state management

• Agent-memory systems track experiences or task progress [25] [28], yet coding observations and test results can become stale as the repository changes.MemTrace binds immutable traces to repository state and records verification, correction, and supersession relations before evidence restoration.Source: §2 · p. 3

Repository-level coding and code graphs

• Code graphs support repository navigation and localization [6] [22] [23], while MemTrace links repository entities to execution evidence so it can be checked against evolving code.Table 1 compares representative methods across history retention, execution and repository structure, and evidence validity.Source: Table 1 · p. 3, §2 · p. 4

3 Method

• When context approaches its budget, MemTrace offloads completed trace bodies and retains compact anchors and synopses for later recovery.After refresh, it reconstructs the execution frontier, validates historical evidence against the current repository, and restores only what the next action requires.Source: §3 · p. 4, §3.1 · p. 5, §3.3 · p. 7

3.1 State-Bound Memory Traces

• Each sealed trace binds completed evidence to its source repository state, referenced files, symbols, and tests, with a compact anchor for stable reference.Later edits create new traces and relations rather than modifying earlier records; offloaded bodies remain in the persistent store.Source: §3.1 · p. 5

3.2 MTG–RSG Projection

• The MTG records execution order and dependencies, verification, correction, and supersession, while the RSG connects task-relevant files, symbols, and tests.Repository bindings support request-specific traversal to candidate traces; structural relations guide retrieval but do not establish historical evidence validity.Source: §3.2 · pp. 5–6, Figure 3 · p. 6

3.3 Validated Restoration

• After refresh, MemTrace reconstructs task progress, locates relevant repository entities, and restores only evidence that is applicable and fits the remaining context budget.Applicability checks recorded source conditions; for test results, both the test and its recorded dependencies must be checked.Source: §3.3 · pp. 6–7

4.1 Experimental Setup

• The evaluation uses DeepSWE, SWE-EVO, and SWE-Milestone under Codex CLI and mini-swe-agent with a shared backbone; SWE-EVO scoring covers 46 tasks.The benchmarks cover repository-level engineering, release-history software evolution, and milestone-based development.Source: §4 · p. 7, §4.1 · p. 7

4.2 Main Results

• MemTrace achieves the best primary metric in every benchmark–harness setting, while baseline performance changes substantially across harnesses.Table 2 reports the main results across the three benchmarks and two harnesses.Source: §4.2 · p. 8, Table 2 · p. 8
• MemTrace exceeds RepoGraph by more than 26 points on DeepSWE’s Python subset under Codex CLI and 32 points under mini-swe-agent.On SWE-Milestone under Codex CLI, their Python Score, Precision, and Recall are nearly tied, while Resolved Rate rises from 8.3% to 16.7%.Source: §4.2 · p. 8
• 69.6% vs. 65.2% SWE-EVO Resolved Rate under Codex CLI favors MemTrace, despite Observation Masking’s higher Fix Rate of 72.1% vs. 70.6%.Under mini-swe-agent, MemTrace also has a higher Resolved Rate than the best baseline (63.0% vs. 52.2%) despite a lower Apply rate (93.5% vs. 97.8%).Source: §4.2 · p. 8

4.3 Analysis

• Adding the MTG raises DeepSWE from 32.1% to 44.2% pass@1, and adding the RSG raises it further to 56.6%.On SWE-EVO, removing the RSG leaves performance unchanged at 69.6%; the passage suggests repository grounding matters more for broader, heterogeneous repositories.Source: §4.3 · p. 9
• Among 9,226 eligible file-bound Memory Traces, 57.0% encounter a later change to at least one bound file; exposure correlates with repository revisions (Spearman ρ = 0.49).The estimated probability that bound files remain unchanged falls to about 0.50 after 1,000 logged event steps.Source: §4.3 · p. 9, Figure 4 · p. 9
• Across short, medium, and long DeepSWE horizons, median traces rise 79→102.5→129, revisions 21→30→41, and semantic invalidations 122→142→223.Exposure rate shows no clear monotonic increase with execution length, so the increased maintenance load is associated mainly with more history and repository changes.Source: §4.3 · p. 10

5 Conclusion and Future Work

• MemTrace preserves execution evidence with repository provenance and validates that evidence before reuse.The conclusion frames long-horizon memory as maintaining both historical information and its applicability to the current execution state.Source: §5 · p. 10
• Across long-horizon benchmarks, MemTrace improves the primary task-level metric over fully evaluated baselines across two agent harnesses.The analyses report complementary value from structured execution memory and repository-state grounding.Source: §5 · p. 10
• Future work will evaluate additional backbone models and context-window sizes and extend MemTrace to persistent development across tasks and sessions in one repository.Source: §5 · p. 10

A.1 Benchmark Composition

• DeepSWE contains 113 tasks from 91 repositories, SWE-EVO contains 48 tasks from seven Python projects, and SWE-Milestone has seven itineraries and 98 graded milestones.Milestones are graded stages within an itinerary.Source: §A.1 · p. 14
• The SWE-Milestone milestone counts are 23 for go-zero, 9 for Navidrome, 18 for element-web, 13 for Nushell, 11 for ripgrep, 12 for Dubbo, and 12 for scikit-learn.The official catalogue classifies Navidrome under Go.Source: §A.1 · p. 14
• SWE-EVO resolved-rate tables use 46 tasks because two instances fail benchmark validation and are removed before scoring, not counted as unresolved agent attempts.Every DeepSWE rate in Table 5 uses all 113 tasks.Source: §A.1 · p. 14

A.2 Additional Results and Wall-Clock Time

• The DeepSWE Trace Store Only ablation scores 36/112 (32.1%); one task with no official score is excluded from both numerator and denominator.That task’s attempt exited in about 33 seconds and is counted neither as a resolved success nor as a model failure.Source: §A.2 · p. 15
• Component ablations use Codex CLI, share the backbone within each harness setup, and provide symbol-level RSG relations for Python but file-level relations for other languages.Source: §A.2 · p. 15
• Table 6 reports mean elapsed time per task in minutes, rounded to two decimal places, with comparisons made within each harness and benchmark.Source: §A.2 · p. 15, Table 6 · p. 15

• The diagnostics use archived DeepSWE mini-swe-agent trajectories separately from performance runs, with exposure analysis on 9,226 traces from 84 trajectories.Revision, invalidation, and Context Refresh counts use 85 instrumented trajectories; task-level associations use 95% percentile bootstrap intervals from 5,000 resamples.Source: §A.3 · pp. 15–16, Table 8 · p. 16
• 57.0% of eligible file-bound traces encountered a later change to at least one bound file (5,261/9,226; 95% CI: 52.8–61.3%).The pooled rate weights traces equally; exposure records file changes, while Trace Validation assesses whether historical evidence remains applicable.Source: §A.3 · p. 16
• 16,197 invalidations were recorded across 2,897 revisions, but the count measures revision-triggered maintenance under the policy, not independently verified semantic errors.The policy closes global evidence types on any revision and entity-scoped evidence when a bound file, symbol, or test is affected, while retaining the Memory Trace.Source: §A.3 · p. 16
• Across observed-age quartiles, exposure rates were 27.4%, 60.8%, 69.9%, and 70.1%; these descriptive rates have different follow-up lengths.The time-to-change estimate accounts for right censoring at the run endpoint; Figure 4(b) estimates the probability that no bound file has yet changed.Source: §A.3 · pp. 16–17

Execution-length groups

• Execution-length groups use distinct model responses in independent Native mini-swe-agent trajectories, with tasks sorted into three near-equal groups and assignments fixed across metrics.The response count measures observed execution length, not intrinsic task difficulty; Native outcome labels are not used for grouping or performance comparison.Source: §A.4 · p. 17, Table 10 · p. 17

Long-horizon behavior

• From Short to Long, median Memory Trace counts rise from 79 to 129, revisions from 21 to 41, and evidence invalidations from 122 to 223; exposure has no clear monotonic association (ρ = 0.137).Context Refresh count is also positively associated with response count.Source: §A.4 · p. 17, Table 11 · p. 18, Table 12 · p. 18

Alternative execution-length measures

• Native response count correlates with tool calls (ρ = 0.980), wall-clock time (ρ = 0.677), and output tokens (ρ = 0.508); alternative grouping preserves 85.8% of tool-call assignments or 46.0% of output-token assignments.Memory Trace counts and invalidations are positively associated with all three alternative length measures.Source: §A.4 · p. 19, Table 13 · p. 19

Within-run accumulation

• Median cumulative Memory Trace counts reach 23, 52, 75, and 102 across four event-step intervals, while invalidations reach 33, 80, 136, and 158.Figure 6 separates Context Refreshes from the larger trace and invalidation counts.Source: §A.4 · p. 19, Figure 6 · p. 19

Trace and repository evolution

• At step 1,061, trace τA was sealed with a binding to internal/compiler/parser_test.go; at step 17,152, that file changed in a revision recording 15 semantic evidence invalidations.The shared file path and event order establish exposure for τA; the invalidation count applies to the revision, not specifically to this trace.Source: §A.5 · p. 20, Figure 7 · p. 20

Continuation and verification

• After a Context Refresh at step 17,986, two semantic updates were accepted for M003, and a test at step 21,392 returned exit code 0 for criterion M003.C001.The archived score summary records Harbor reward 1.Source: §A.5 · p. 20, Table 14 · p. 20, Figure 7 · p. 20

Interpretation

• The file binding identifies where current applicability must be checked, while the later test supplies evidence about the updated execution state.The case distinguishes preserving history from establishing its current applicability.Source: §A.5 · p. 20