EvoArena Deep Dive: When Environments Keep Changing, Is Your Agent's Memory Still Overwriting Itself?

> Paper: EvoArena: Tracking Memory Evolution for Robust LLM Agents in Dynamic Environments > Authors: Jundong Xu, Qingchuan Li, Jiaying Wu, Yihuai Lan, Shuyue Stella Li, Huichi Zhou, Bowen Jiang, Lei Wang, Jun Wang, Anh Tuan Luu, Caiming Xiong, Hae Won Park, Bryan Hooi, Zhiyuan Hu > Institutions: National University of Singapore, Singapore Management University, University of Washington, UCL, UPenn, NTU, Recursive, MIT > arXiv:2606.13681 > Code: open-sourced at https://github.com/Aiden0526/EvoArena > Date: 2026-06-11

TL;DR

EvoArena identifies a critical blind spot in existing agents: environments change, but memory stores only the latest state. The authors built three dynamic-evolution benchmarks (terminal workflows, codebases, user preferences) and proposed EvoMem—a Git-style patch mechanism that records memory evolution history instead of overwriting. Experiments show an average chain-level accuracy gain of 3.7%, especially significant under continuous environmental change.

The Core Problem: Why Do Agents "Forget" Once Deployed?

Existing LLM agent evaluation assumes a static environment: give a task, run the agent once, score it, done.

The real world is different:

• APIs your scripts depend on change interfaces
• Codebases get new versions, features, and bugs
• User preferences shift over time—today's "like" can become tomorrow's "dislike"

An agent must answer three questions: 1. What changed? (environment evolution detection) 2. What still holds? (retention of old knowledge) 3. How to act under the current version? (adaptation)

But existing agents merge all memory into a single latest state. The authors call this "State Collapse"—still-valid old rules/behaviors get overwritten by new memory, and agents fail completely when the environment rolls back or multiple versions coexist.

EvoArena: Three Real Evolution Scenarios

Scenario 1: Terminal-Bench-Evo (Terminal Workflow Evolution)

• What evolves: terminal dependencies, interfaces, paths, validation rules
• Scale: 89 initial tasks → 352 evolved versions, 441 instances total
• Tests: whether agents can keep executing workflows correctly after interface changes

Example: a data-processing script uses pandas.read_csv in v1, the interface changes in v2, and new validation rules appear in v3. The agent must know the correct call for each version.

Scenario 2: SWE-Chain-Evo (Codebase Evolution)

• What evolves: codebase milestones, new features, bug fixes
• Scale: 50 evolution chains, 493 chain-step instances, 145 unique milestones
• Tests: software engineering tasks in a continuously evolving codebase

Key design: after step t, reference milestone updates (not the agent's own patches) form the step t+1 repository state. This isolates "adapting to an evolving repo" from "early error accumulation."

Scenario 3: PersonaMem-Evo (User Preference Evolution)

• What evolves: user preferences, style, temporal validity
• Scale: 10 persona conversations, 505 questions, 313 preference chains
• Tests: tracking temporal trajectories of user preferences

Four question types: single-pattern transfer, multi-pattern synthesis, conflict resolution, and temporal trajectory (extrapolating preference evolution).

EvoMem: Git-Like Patch-Based Memory—No More Overwriting

Existing memory systems overwrite old state on update, losing evolution history. EvoMem:

• Append-only, no overwriting—like Git commit history
• Each patch records 6 elements: timestamp, pre-update content, post-update content, update rationale, semantic summary, supporting evidence
• Uses latest memory by default at inference—like a normal agent
• When older-version knowledge is needed—retrieves relevant patches to restore the valid state

Trigger Condition: Only Record "Non-Additive Updates"

Not every observation creates a patch. Only modifications, overwrites, or reinterpretations of memory trigger patches. Purely additive observations don't.

Cross-Agent Instantiation

| Agent | Base Memory | What Patches Record | |-------|-------------|---------------------| | Terminus2 (terminal) | Distilled task-solving knowledge | Strategy changes from terminal environment shifts | | OpenHands (SE agent) | Distilled SE context | Superseded implementation strategies, revised logic | | A-Mem (conversational) | Semantic notes and links | Note and relation updates | | Memento-S (skill memory) | Global reusable skill files | Task-specific prompt updates, trigger failures |

Results: How Fragile Are Agents in Dynamic Environments?

Baseline Chain-Level Accuracy Is Dire

| Benchmark | Step-Level Acc | Chain-Level Acc | |-----------|----------------|-----------------| | Terminal-Bench-Evo | 43.6% | 21.5% | | SWE-Chain-Evo | 27.9% | 10.0% | | PersonaMem-Evo | 47.3% | 40.0% |

Chain-level accuracy means "correct from start to finish." 10–40% shows agents can barely maintain long-term reliability under continuous change—one wrong step, everything after fails.

EvoMem Gains

| Benchmark | Step-Level Gain | Chain-Level Gain | Key Finding | |-----------|-----------------|------------------|-------------| | Terminal-Bench-Evo | +2.4% | +6.1% | Chain-level gain is 2.5× step-level | | SWE-Chain-Evo | +0.4% | +2.1% | Hardest benchmark, still improves | | PersonaMem-Evo | +1.7% | +3.2% | Temporal trajectory questions benefit most | | Average | +1.5% | +3.7% | Chain > Step |

Core insight: EvoMem improves "continuous reliability" far more than "single-step correctness." That's exactly what dynamic environments need—not perfection every step, but recovery after errors and adaptation to change.

Best Case

Terminal-Bench-Evo + GPT-5.5: chain-level accuracy rises from 31.8% to 45.5% (+13.7 points). In continuously evolving terminal workflows, EvoMem takes the agent from "barely reliable" to "nearly half of full chains correct."

Gains on Standard Benchmarks

| Benchmark | Agent | Baseline | +EvoMem | Gain | |-----------|-------|----------|---------|------| | GAIA | Memento-S | 65.8% | 72.3% | +6.5% | | LoCoMo | A-Mem | 39.7% | 43.0% | +3.3% |

EvoMem also helps on benchmarks without explicit evolution—because implicit environmental change is everywhere in real tasks.

Ablations: What's Actually Working?

Finding 1: Patches Must Be "Adopted" to Help

Terminal-Bench-Evo analysis:

| Condition | Baseline | +EvoMem | Gain | |-----------|----------|---------|------| | Patch retrieved but not adopted | 46.8% | 49.4% | +2.6% | | Patch retrieved and adopted | 80.6% | 88.9% | +8.3% |

EvoMem isn't just adding context—the key is whether the agent can operationalize retrieved transition information (identify local changes, keep valid parts, revise stale parts).

Finding 2: Lower SWE Chain-Level Failure Rates

Pass-to-Pass failure rate (breaking historical behavior when implementing new requirements):

| Model | Baseline | +EvoMem | Reduction | |-------|----------|---------|-----------| | Qwen3.6-27B | 9.01% | 6.73% | -2.28% | | Kimi-K2.6 | 7.14% | 3.33% | -3.81% |

EvoMem helps agents preserve historical behavior constraints—new features no longer break old ones.

Finding 3: PersonaMem Question-Type Split

| Question Type | Baseline | +EvoMem | Gain | |---------------|----------|---------|------| | Conflict resolution | 29.5% | 28.6% | -0.9% | | Single-pattern transfer | 46.2% | 44.4% | -1.8% | | Multi-pattern synthesis | 38.8% | 44.0% | +5.2% | | Temporal trajectory | 46.6% | 51.7% | +5.2% |

EvoMem helps most on temporal trajectory tracking and multi-pattern synthesis—precisely where State Collapse is worst.

Efficiency–Accuracy Trade-Off: More Tokens ≠ Better Results

PersonaMem-Evo:

• GPT-5.5: 40.3% accuracy with 69.2M tokens (highest)
• Kimi-K2.6: 51.5% accuracy (second best) with 24.5M tokens (lowest)
• Gemma-4-31B: 52.6% accuracy (best) with 27.1M tokens (below average)

Terminal-Bench-Evo:

• GPT-5.5: 62.8% accuracy (highest), but 505.0M tokens (extremely high)
• Gemini-3.1 Pro / GLM-5.1: 53.8% / 51.8% accuracy with 79.2M / 80.3M tokens (far below the 203.6M average)

Conclusion: a larger token budget doesn't mean better performance. EvoMem's design lets mid-size models exploit memory history efficiently rather than just burning tokens.

Why This Matters

1. State Collapse is an implicit bug in agents. Existing memory systems (Mem0, A-Mem, LangGraph, etc.) assume "latest = best." But in the real world, API v1 interfaces deprecated in v2 may return in v3; features users hated last year are must-haves this year; old codebase constraints remain valid in new versions. Merging into a single state discards all context. EvoMem's patch history preserves "why it changed" and "what it used to be." 2. Chain-level accuracy is the real-world metric. Current evaluation only checks single-step accuracy; real deployments care about how long agents run without errors. EvoArena's chain-level evaluation reveals baseline fragility: only 10–40%. 3. Lightweight, plug-and-play. EvoMem doesn't replace existing memory systems—it adds a patch layer on top. No model changes, no fine-tuning, no retraining—just monitor non-additive updates and append records. 4. Validated across domains. Terminal workflows, codebases, and user preferences—three entirely different dynamic domains, all improved. This suggests State Collapse is a general problem and patch history is a general solution.

Limitations and Reflections

| Limitation | Notes | |------------|-------| | Limited evolution scope | Doesn't cover multimodal perception evolution or physical environment changes | | Patch creation overhead | Non-additive update detection and structuring may bottleneck in extreme high-frequency scenarios | | Retrieval precision | Patch retrieval accuracy directly affects restoration; retrieval errors may inject noise | | Storage bloat | Long-running agents may accumulate very long patch histories, requiring compression/archiving | | Untested RAG integration | Synergy with external vector databases not evaluated |

TL;DR (Again)

EvoArena shows that agents aren't unreliable because they can't remember—they're unreliable because they only remember "now," forgetting "what was" and "why it changed." Replacing overwrite-save with Git-style patch history lets agents know what changed, what still holds, and how to act under the current version.

> "Memory is not a snapshot—it is an evolution history."

Reference: Jundong Xu et al. "EvoArena: Tracking Memory Evolution for Robust LLM Agents in Dynamic Environments." arXiv:2606.13681, 2026.