Capability-Driven Self-Evolution of Agent Memory

1 Introduction

• Memory supports diverse information and requests, but holistic evolution combines capability feedback and judges progress mainly by overall performance.The paper frames effective memory as multidimensional, with distinct yet interconnected capabilities.Source: §1 · p. 1
• 80.5% of revisions without an overall gain still improve at least one capability, so overall scores can obscure useful gains.The paper notes this masking is especially pronounced near a performance plateau.Source: §1 · p. 2
• Capability-driven evolution uses capability-specific feedback and evaluation to preserve promising revisions and broaden exploration beyond overall-performance guidance.Figure 1 contrasts the limited region explored by holistic evolution with broader exploration through explicit capability directions.Source: §1 · p. 2, Figure 1 · p. 2
• PRISMEM prioritizes capabilities with potential cross-capability benefits, diagnoses informative failures using history, and integrates specialists through paired differential cases.The integration compares program behavior on the same tasks to consolidate complementary gains.Source: §1 · p. 2
• 7.83–10.54 pp: PRISMEM outperforms the strongest baselines on million-token histories.The paper reports this range across BEAM and LongMemEval.Source: §1 · p. 2

2 Background and Related Work

• Static memory systems use fixed storage and retrieval strategies, with different systems emphasizing factual retrieval, temporal tracking, preferences, or multi-session synthesis.The cited examples include Mem0 and SimpleMem for factual retrieval, Zep and Hindsight for temporal tracking, and A-MEM and related systems for synthesis.Source: §2 · p. 3
• Self-evolving methods use task feedback to refine memory structures or strategies, producing a fixed program; some optimize retrieval configurations while others evolve full programs.EvolveMem focuses on configuration-level optimization, whereas M⋆, MemEvolve, and MemPro pursue program-level evolution.Source: §2 · p. 3
• Existing self-evolving methods rely on overall scores, which can blur revision directions and mask capability gains offset by regressions.The paper identifies these effects as contributing to stagnant evolution.Source: §2 · p. 3

3 PrisMem: Capability-Driven Memory Evolution

• The problem formulation optimizes an executable memory program on history-question tasks, using training and validation during evolution before freezing the best program for test evaluation.The fine-grained interface divides the program into extraction, indexing, planning, retrieval, and answer components for more localized revisions.Source: §3 · p. 3

3.1 Capability-Driven Evolution

• PRISMEM organizes evolution around five representative memory capabilities selected from recurring requirements in benchmarks and memory systems.Offline LLM annotations assign training and validation tasks one primary capability and up to two secondary capabilities; these labels are not given to the memory program during evaluation.Source: §3 · p. 3, Table 1 · p. 4

3.1.1 Stage I: Cold Start

• Cold start uses five rounds of capability-wise feedback to establish a balanced base program and retains evolution history for later refinement.A capability-by-component diagnostic table helps localize early weaknesses in extraction, indexing, and retrieval.Source: §3.1.1 · p. 4

3.1.2 Stage II: Capability Refinement

• Capability refinement selects weak capabilities or those with cross-capability bottleneck effects, then starts revisions from each target’s best-performing specialist.History-guided diagnosis selects severe, actionable, diverse failures; past programs’ performance on them helps identify regression witnesses while repeated cases and capability combinations are discounted.Source: §3.1.2 · pp. 4–6

3.1.3 Stage III: Trace-guided Integration

• Trace-guided integration compares the base program and specialists on paired cases with the largest score gaps to expose behavioral differences and guide consolidation.Integration proceeds from specialists closest to the base program in lineage; failed integrations can be revised if overall performance does not improve or a capability drops beyond the threshold.Source: §3.1.3 · p. 6

3.2 Efficient Evolution

• Compact diagnostic contexts reduce diagnostic-case token cost by 44% on average, while revision-aware execution reuses outputs from unaffected components.For example, a retrieval-only revision can reuse constructed memory and skip extraction and indexing.Source: §3.2 · p. 6

4.1 Experimental Setup

• Methods train for 20 iterations on smaller benchmark splits and are tested on longer splits with different content, including histories exceeding one million tokens.Task performance uses benchmark-provided LLM judge scores; capability scores group questions by native question type.Source: §4.1 · p. 7

4.2 Overall Performance (Q1)

• PRISMEM improves overall scores by 7.83–10.54 pp over the strongest self-evolving baselines and leads in nearly all capability comparisons.The comparison covers BEAM-1M and LongMemEval-M; token usage is comparable to other methods.Source: §4.2 · p. 7, Table 2 · p. 8
• Programs evolved on smaller splits retain advantages on longer histories, and PRISMEM also outperforms baselines by 6.17–20.41 pp on BEAM-1M with GPT-5.5.Additional cross-model and cross-dataset transfer experiments support transferability.Source: §4.2 · p. 7

4.3 Evolution Efficiency (Q2)

• PRISMEM reduces evolution cost by 4%–30% versus M⋆ under the same 20-round budget, using compact diagnostic contexts and revision-aware execution reuse.LongMemEval has higher evolution costs because each question has an independent history and higher per-round extraction costs.Source: §4.3 · pp. 7–8, Table 3 · p. 7

4.4 Ablation Study (Q3)

• Removing capability-driven evolution reduces the BEAM score by 10.15 pp, the largest reported ablation drop.The variant reverts to holistic evolution, where mixed feedback can blur directions and capability-specific revisions may not receive further refinement.Source: §4.4 · p. 8, Table 4 · p. 8
• Removing trace-guided integration reduces the score by 3.16 pp; round-robin selection reduces it by 2.55 pp, and random case selection by 5.26 pp.Capability-focused refinement still beats baselines without integration; targeted capability selection and objective-matched diagnostic cases support further gains.Source: §4.4 · p. 8, Table 4 · p. 8

4.5 Evolution Trace Analysis (Q4)

• Capability scores improve intermittently during Stage II, and the final integrated program closely matches the historical capability-wise peak while expanding beyond holistic evolution’s boundary.Refining one capability can also update specialists for others, reflecting dependencies among capabilities.Source: §4.5 · p. 9, Figure 3 · p. 9

5 Conclusion

• PRISMEM combines dependency-aware capability selection and history-guided specialist refinement with trace-guided integration of complementary gains into a unified memory program.The approach expands optimization along explicit capability dimensions; on million-token histories, it outperforms the strongest baselines by 7.83–10.54 pp.Source: §5 · p. 9

A.1 Capability Selection and Offline Annotation

• Only 337 of 700 BEAM-1M questions (48.14%) received the benchmark-type primary capability label under question-only GPT-5.5 annotation.The study therefore annotates training and validation questions using the question, reference answer, and evidence, assigning one primary and up to two secondary capabilities; labels are not passed to the memory program.Source: §A.1 · pp. 12–13

A.2 Evidence-Based Diagnostic Metrics

• Evidence-based diagnostics separately measure whether reference evidence is preserved in extracted units, accessible through an oracle evidence query, and retrieved for the actual question.Comparing these measures helps localize weaknesses to extraction, indexing, or query planning and retrieval.Source: §A.2 · pp. 13–14

A.3 Diagnostic Case Presentation and Compression

• PRISMEM diagnostic cases pair reference evidence with source text and memory units, while compression reduces average BEAM trace context from 16,776 to 9,428 tokens (43.8%).Long excerpts are limited to 2,400 characters and selected for relevance to the question, answer, evidence, and prediction; memory excerpts retain at least the best-matching unit for each evidence snippet.Source: §A.3 · p. 14

A.4 Validate Generated Programs

• Generated revisions undergo source, schema, signature, smoke-test, and synthetic-complexity checks before task-model calls are allocated.The checks reject incomplete or incompatible programs and bound execution cost using a local CPU-work budget and outer timeout.Source: §A.4 · p. 15

A.5 Memory Interface.

• The five memory components are Extraction, Indexing, Planning, Retrieval, and Answer, and evolution may modify their schemas, code, and instructions.The interface supports chronological session indexing and retrieval from dense, lexical, exact-value, graph, or metadata indexes, subject to a 16,000-character output limit.Source: §A.5 · pp. 15–16

A.6 Revision-Aware Execution Reuse

• Revisions re-execute from the earliest affected pipeline stage, reusing unaffected state while copying it to keep parent and candidate memory states separate.For example, a changed ranking rule can reuse extracted units and built memory, whereas a changed extraction instruction requires downstream recomputation.Source: §A.6 · pp. 16–17

A.7 Seed Memory Program

• The seed program appends extracted units in input order and returns their concatenation truncated to the fixed 16,000-character budget, without query-dependent ranking.It is deliberately simple to provide a broad search space for PRISMEM.Source: §A.7 · p. 17
• The seed program appends each indexed unit’s memory text and retrieves the memories joined by blank lines, truncated to OUT_CHAR_BUDGET.Its interface defines separate index and retrieve methods.Source: §A.7 · p. 17

A.8 Pseudocode of PrisMem

• PrisMem starts from seed P0, revises programs using diagnosed metrics, retains successful evaluations, and selects the highest-validation-score program as the refinement base.The pseudocode then initializes each capability’s specialist from that base.Source: §A.8 · p. 18
• During capability refinement, PrisMem selects a capability, curates cases, diagnoses and revises its specialist, and retains a candidate only if it passes capability and full-suite evaluation.Unsuccessful candidates leave the existing specialist set unchanged.Source: §A.8 · p. 18
• During integration, PrisMem uses paired cases to plan and execute specialist-gain integration, accepting a program only when its overall score improves and its maximum capability loss stays within θ.If integration fails, the pseudocode accumulates cases for another attempt.Source: §A.8 · p. 18

B.1 Dataset Splits and Capability Composition

• Frozen programs evolved on ∼100K-token BEAM and LongMemEval histories are evaluated on their million-token test splits.The authors describe this setup as reducing overfitting risk and providing a more direct test of generalization to million-token histories.Source: §B.1 · p. 19
• BEAM uses 160 training and 120 validation questions from separate conversations, with 700 BEAM-1M test questions from 35 other conversations.LongMemEval uses 60 training and 60 validation questions, plus a stratified 200-question LongMemEval-M test subset with different histories.Source: §B.1 · p. 19

B.2 Parameter Settings

• Experiments use Qwen3.8-27B and GPT-5.5, with 20 evolution rounds and PRISMEM allocating 5 to cold start, 12 to refinement, and 3 to integration.The reported settings use the same inference parameters across methods; task-model thinking is disabled or low, while diagnosis and coding use medium reasoning effort.Source: §B.2 · p. 19, Table 8 · p. 19

C.1 Results on GPT-5.5

• GPT-5.5 results on BEAM preserve the trends observed with Qwen3.8-27B, supporting robustness across underlying models.Table 9 reports performance on BEAM with GPT-5.5.Source: Table 9 · p. 20, §C.1 · p. 20

C.2 Transfer Experiments

• Programs evolved with Qwen3.8-27B on BEAM-100K are tested with GPT-5.5 on BEAM-1M and with Qwen3.8-27B on LongMemEval-M.The remaining settings match the main experiments.Source: §C.2 · p. 20
• Evolved memory programs maintain strong performance across model and dataset transfers without additional program optimization.The model-transfer evaluation uses GPT-5.5 on BEAM-1M; the dataset-transfer evaluation uses Qwen3.8-27B on LongMemEval-M.Source: §C.2 · p. 20, Table 10 · p. 20, Table 11 · p. 20

C.3 Capability Router Experiments

• On BEAM-1M with Qwen3.8-27B, integration outperforms question-only routing by 5.65 pp and oracle-label routing by 1.12 pp, supporting integration of useful capability-specific revisions into a shared memory program.Source: Table 12 · p. 21, §C.3 · p. 21

D Detailed Evolution Trace

• Table 13 records BEAM evolution failures, revisions, and program components; blue tags mark targets, while gray boxes mark capability specialists.A specialist is a resulting node that achieves the best score for a capability.Source: D Detailed Evolution Trace · p. 21, Table 13 · p. 21

Stage I: Cold-start revisions

• Stage I diagnosed that one flat query missed complementary evidence across sessions by over-concentrating retrieval on one semantic aspect of synthesis questions.Source: Stage I: Cold-start revisions · p. 21

Stage II: Capability-directed refinement

• Stage II addressed fragmented evidence and lost temporal provenance with aspect-wise subqueries, topic grouping, and session dates on memory units.Source: Stage II: Capability-directed refinement · pp. 21–22
• Stage II also addressed omitted standing preferences and fragmented synthesis with reserved preference retrieval and concise chronological, counting, and format guidance.Source: Stage II: Capability-directed refinement · p. 22, Stage III: Final integration · p. 22
• Stage II addressed missed negations and conflated speakers by retrieving both affirmative and negative evidence and labeling user-sourced memory units.Source: Stage II: Capability-directed refinement · p. 22, Stage III: Final integration · p. 22

Stage III: Final integration

• Stage III notes that specialist mechanisms can undermine relevance, temporal order, or contradiction handling when combined, motivating conservative integration.Source: Stage III: Final integration · p. 22

E Cases and Suggested Revisions on Different Capabilities

• Three BEAM cases contrast revisions with different capability effects and show how evaluated programs can guide integration of complementary improvements.Source: E Cases and Suggested Revisions on… · p. 23

• Temporal tracking increased by 3.41 pp, while adversarial handling decreased by 14.06 pp when related information was grouped into single memory units.Source: §E.1 · p. 23
• Adversarial handling increased by 12.89 pp, while temporal tracking decreased by 6.90 pp after distinct facts were stored independently.Source: §E.1 · p. 23
• Temporal tracking increased by 0.87 pp, and adversarial handling increased by 2.73 pp after a revision that preserved complete processes while storing contradictory claims separately.Source: §E.1 · p. 23

• Temporal tracking increased by 5.61 pp, while adversarial performance decreased by 9.38 pp when answers were organized chronologically.Source: §E.2 · p. 23
• Adversarial handling increased by 8.20 pp, while temporal tracking decreased by 4.25 pp after answers required explicit causal evidence.Source: §E.2 · p. 23
• Temporal tracking increased by 2.71 pp, and adversarial handling increased by 8.59 pp after guidance distinguished chronological ordering from explicit causal links.Source: §E.2 · p. 23

E.3 Case 3: Increase retrieval diversity versus tighten relevance filtering.

• MMR diversity increased multi-session synthesis by 7.08 pp but decreased temporal tracking by 5.95 pp; stricter relevance filtering increased temporal tracking by 5.87 pp but decreased synthesis by 5.62 pp.Diversity broadened evidence but could mix records from other events; stricter filtering focused on the target event but excluded aspects needed for broad synthesis.Source: §E.3 · p. 24
• 3.92 pp higher multi-session synthesis and 3.70 pp higher temporal tracking followed question-adaptive MMR weighting: diversity for synthesis and relevance for temporal or progression questions.The suggested weights are 0.6 for diversity and 0.7 for relevance.Source: §E.3 · p. 24

F Prompt Catalog

• The prompt catalog uses reflection and refinement coder templates in Stages I–II and planning and integration coder templates in Stage III.The diagnosis prompt context describes five capabilities and asks agents to adapt query planning and retrieval where appropriate.Source: F Prompt Catalog · p. 24

Stage II: capability refinement

• Stage II refinement prompts ask for one target-capability diagnosis and change, considering both instruction optimization and memory design.The refinement output is grounded in implementation, measurements, revision history, and representative cases.Source: Stage II: capability refinement · pp. 25–26

G.1 BEAM Final Memory Program

• BEAM’s program groups related facts by topic, distinguishes cross-topic standing preferences, and plans separate retrieval subqueries for multi-aspect questions.It weights cosine similarity at 0.7 and lexical query-token coverage at 0.3, adds a 0.05 topic bonus, and reserves up to 400 characters for preferences within a 16,000-character context budget.Source: §G.1 · p. 29
• BEAM’s answer instructions distinguish session dates from event dates, handle sums and running totals differently, apply retrieved preferences, and surface contradictions or insufficient evidence.Source: §G.1 · p. 29

G.2 LongMemEval Final Memory Program

• LongMemEval’s program retrieves dated atomic memories from a flat dense index using one tailored query, retaining units scoring at least 0.25 within a 16,000-character context budget.Its answer instructions apply remembered constraints, use date prefixes for temporal calculations, aggregate distinct occurrences, and abstain when a specific fact is unsupported.Source: §G.2 · p. 34
• For recommendations, the program treats relevant preferences and personal context as useful evidence, applies every stated constraint, and forbids abstention when such context exists.For factual near-misses, it instead requires an exact match and says to report unavailable information rather than substitute a similar fact.Source: §G.2 · pp. 35–36
• Temporal and aggregate questions require exact date-based ordering or calculations across all relevant memories, while verification must confirm the specific role, title, or condition asked about.Across question types, answers should remain concise and preserve entity names, dates, and values exactly as retrieved.Source: §G.2 · pp. 35–36
• Retrieval ranks embedded memories by query similarity and selects date-tagged items scoring at least 0.25 until the output-character budget is reached.The program stops when scores fall below the threshold or adding a memory would exceed the budget.Source: §G.2 · p. 37