AutoMem: A Text-Gradient Recursive Self-Improvement Framework for Automated Memory Architectures Search

# AutoMem: A Text-Gradient Recursive Self-Improvement Framework for Automated Memory Architectures Search
Source: [https://arxiv.org/html/2608.14621](https://arxiv.org/html/2608.14621)
Lin Du1, Jie Zhou1,2111Corresponding Author, Yuxuan Cai1, Kai Chen2, Qin Chen1, Xin Li2, Bo Zhang2, Wei Li2, Liang He1 1School of Computer Science and Technology, East China Normal University, Shanghai 2Shanghai AI Laboratory \{jzhou, qchen, lhe\}@cs\.ecnu\.edu\.cn [https://github\.com/ECNU\-ICALK/AutoMem](https://github.com/ECNU-ICALK/AutoMem)

###### Abstract

Long\-term memory is increasingly central to LLM agents, yet memory design remains a highly coupled architecture problem: what to encode, how to store it, how to retrieve it, and how to manage it can vary substantially across tasks and backbone models\. We construct a discrete search space with 5 encoders, 5 stores, 6 retrievers, and 4 managers, and show that no single memory architecture consistently dominates: different tasks favor different module combinations, leading to substantial performance gaps\. Motivated by this, we proposeAutoMem, a text\-gradient recursive self\-improvement framework for task\-adaptive memory architecture search\.AutoMemoptimizes over the factored space through two components: Experience\-Guided Architecture Search, which proposes candidate architectures from historical search trajectories and accumulated reflections, and Failure\-Guided Module Diagnosis, which localizes memory\-related failures to specific modules and converts them into targeted textual feedback\. Experiments on GAIA, WebWalkerQA, and xBench\-DeepSearch across two LLM backbones show thatAutoMemconsistently discovers task\-adaptive memory architectures that outperform the strongest human\-designed memory baselines, improving accuracy by2\.82\.8points on average across six benchmark\-backbone settings\. Further analysis shows thatAutoMemachieves a favorable accuracy\-efficiency trade\-off, reducing token cost by14\.3%14\.3\\%over the strongest accuracy baselines under Qwen3\.5\-122B\-A10B, while also finding stronger architectures than substantially larger random searches within only a few guided iterations\.

## 1Introduction

Long\-term memory has become an important component of LLM agents\[[1](https://arxiv.org/html/2608.14621#bib.bib1)\]\. It enables agents to preserve reusable information from past interactions, trajectories, and task executions, and to reuse such information in future decision making\. Existing work has explored episodic memory over dialogues and trajectories\[[2](https://arxiv.org/html/2608.14621#bib.bib2),[3](https://arxiv.org/html/2608.14621#bib.bib3),[4](https://arxiv.org/html/2608.14621#bib.bib4),[5](https://arxiv.org/html/2608.14621#bib.bib5)\], verbal reflection and distilled experience\[[6](https://arxiv.org/html/2608.14621#bib.bib6),[7](https://arxiv.org/html/2608.14621#bib.bib7)\], procedural memory in the form of skills, workflows, or test\-time cheatsheets\[[8](https://arxiv.org/html/2608.14621#bib.bib8),[9](https://arxiv.org/html/2608.14621#bib.bib9),[10](https://arxiv.org/html/2608.14621#bib.bib10),[11](https://arxiv.org/html/2608.14621#bib.bib11)\], and structured experience sharing across agents\[[12](https://arxiv.org/html/2608.14621#bib.bib12)\]\. These systems show that agent memory is no longer a single retrieval\-augmented store, but a multi\-module subsystem involving decisions about what to encode, how to store it, how to retrieve it, and how to maintain it over time\[[13](https://arxiv.org/html/2608.14621#bib.bib13)\]\.

However, most memory systems are still manually designed and fixed once deployed\. This is limiting because memory effectiveness depends on interactions among multiple modules\. A task may fail because useful information was not encoded, because the stored representation is hard to retrieve, because the retriever selects irrelevant memories, or because the memory pool contains stale, duplicated, or conflicting entries\. Therefore, improving agent memory requires optimizing the full memory architecture rather than tuning a single retrieval component\.

To study this problem systematically, we factor long\-term memory into four modules: Encode, Store, Retrieve, and Manage\. Encode decides what information should be written into memory, Store decides how the memory is represented, Retrieve decides how relevant memories are selected, and Manage controls memory consolidation, deduplication, eviction, and conflict resolution\. Based on common designs in prior memory systems, we construct a discrete search space with 5 encoders, 5 stores, 6 retrievers, and 4 managers\. This turns memory design into a memory architecture search problem over𝒜=ℰ×𝒮×ℛ×ℳ\\mathcal\{A\}=\\mathcal\{E\}\\times\\mathcal\{S\}\\times\\mathcal\{R\}\\times\\mathcal\{M\}\.

Our pilot study shows that architecture choice is a major source of performance variation\. Simple search over the factored space can discover architectures that match or outperform strong fixed memory baselines\. More importantly, the best architecture differs across datasets and backbone models, and module effects are strongly coupled\. For example, a strong retriever may still fail when the encoder writes low\-quality memories, while a useful store format may be ineffective if the retriever cannot query it properly\. These findings suggest that memory architecture search is valuable, but exhaustive or random search is expensive because each candidate requires a full agent rollout and provides little reusable optimization signal\.

We proposeAutoMem, a text\-gradient recursive self\-improvement framework for task\-adaptive memory architecture search \(Figure[2](https://arxiv.org/html/2608.14621#S4.F2)\)\.AutoMemcontains two components\. Experience\-Guided Architecture Search proposes candidate architectures from historical search trajectories, evaluated architectures, performance records, and accumulated reflections\. Failure\-Guided Module Diagnosis analyzes failed rollouts, localizes memory\-related failures to Encode, Store, Retrieve, or Manage, and converts them into targeted textual feedback for the next search round\. Through repeated proposal, evaluation, diagnosis, and validation,AutoMemturns failed trajectories into directional signals for improving memory architectures\. We evaluateAutoMemon GAIA, WebWalkerQA, and xBench\-DeepSearch across multiple LLM backbones\. Experiments show thatAutoMemdiscovers task\-adaptive memory architectures that outperforms all the strong baselines, while reducing per\-task token cost\. Moreover,AutoMemsteadily improves the quality of discovered memory architectures across iterations and quickly identifies superior architectures within only a few rounds, outperforming those found by substantially larger random searches\.

Our contributions are threefold:

- •We systematize the design space of long\-term memory for LLM agents by factorizing memory architectures into Encode, Store, Retrieve, and Manage modules, and empirically study which module designs and cross\-module interactions are most critical to memory effectiveness\.
- •We proposeAutoMem, a recursive self\-improvement framework for efficiently identifying task\-adaptive memory architectures under limited evaluation budgets, combining experience\-guided architecture search with failure\-guided module diagnosis\.
- •We conduct experiments on GAIA, WebWalkerQA, and xBench\-DeepSearch across multiple LLM backbones, showing that task\-adaptive memory architectures outperform human\-design framework\.

## 2Related Work

#### Memory architectures for LLM agents\.

Long\-term memory has become an important component of LLM agents\. Existing methods store and retrieve episodic experience by summarizing dialogues or trajectories into memory stores and retrieving them by relevance\[[2](https://arxiv.org/html/2608.14621#bib.bib2),[3](https://arxiv.org/html/2608.14621#bib.bib3),[4](https://arxiv.org/html/2608.14621#bib.bib4),[5](https://arxiv.org/html/2608.14621#bib.bib5)\], distill verbal self\-reflections and cross\-task insights for reuse\[[6](https://arxiv.org/html/2608.14621#bib.bib6),[7](https://arxiv.org/html/2608.14621#bib.bib7)\], induce procedural memory such as reusable skills, workflows, or test\-time “cheatsheets”\[[8](https://arxiv.org/html/2608.14621#bib.bib8),[9](https://arxiv.org/html/2608.14621#bib.bib9),[10](https://arxiv.org/html/2608.14621#bib.bib10),[11](https://arxiv.org/html/2608.14621#bib.bib11)\], or share structured experience across agents\[[12](https://arxiv.org/html/2608.14621#bib.bib12)\]\. These studies demonstrate that memory can improve agent learning, reasoning, and reuse across tasks\. However, they also show that memory is not a single retrieval component, but a coupled architecture involving what to encode, how to store it, how to retrieve it, and how to maintain it over time\[[13](https://arxiv.org/html/2608.14621#bib.bib13)\]\. Most existing systems manually choose one memory configuration and keep it fixed\. In contrast,AutoMemsystematizes these design choices into a discrete Encode/Store/Retrieve/Manage space and treats the memory architecture itself as an optimizable variable\.

#### Self\-Evolving Memory\.

A closer line of work studies adaptive or self\-evolving memory systems\. Zhang et al\.\[[14](https://arxiv.org/html/2608.14621#bib.bib14)\]meta\-evolves the whole memory system by synthesizing new memory implementations from execution logs and selecting candidates through tournament evaluation\. This approach increases the flexibility of memory design, but each candidate is a monolithic implementation, making it difficult to assign credit to individual memory modules or perform controlled module\-level edits\. Liu et al\.\[[15](https://arxiv.org/html/2608.14621#bib.bib15)\]introduces a structured diagnosis loop with revert\-on\-regression, but it mainly adapts retrieval configurations for dialogue\-QA memory\. More broadly, automated agent design methods search over code\-defined agents\[[16](https://arxiv.org/html/2608.14621#bib.bib16)\], workflows\[[17](https://arxiv.org/html/2608.14621#bib.bib17)\], agent graphs\[[18](https://arxiv.org/html/2608.14621#bib.bib18)\], symbolic agent parameters\[[19](https://arxiv.org/html/2608.14621#bib.bib19)\], or self\-modifying coding agents\[[20](https://arxiv.org/html/2608.14621#bib.bib20)\], but they mainly optimize prompts, tools, workflows, or orchestration rather than the memory subsystem\.AutoMemdiffers from these methods by performing structured, per\-module\-attributable search over all four memory modules\. This enables valid\-by\-construction candidates, controlled architecture edits, and task\-adaptive memory optimization on agentic web tasks\.

#### Text\-gradient Optimization\.

AutoMemis also related to textual\-gradient and failure\-driven optimization\. Prior work treats LLM\-generated natural\-language feedback as an optimization signal\.ProTeGiuses textual “gradients” to critique and edit prompts\[[21](https://arxiv.org/html/2608.14621#bib.bib21)\],TextGradpropagates textual feedback through a computation graph\[[22](https://arxiv.org/html/2608.14621#bib.bib22)\], and OPRO andDSPyuse LLMs to optimize prompts or pipeline parameters\[[23](https://arxiv.org/html/2608.14621#bib.bib23),[24](https://arxiv.org/html/2608.14621#bib.bib24)\]\. These methods mainly optimize a single text object, prompt, or pipeline parameter, rather than a structured memory architecture\. Another line attributes agent failures to responsible steps or modules\[[25](https://arxiv.org/html/2608.14621#bib.bib25),[26](https://arxiv.org/html/2608.14621#bib.bib26),[27](https://arxiv.org/html/2608.14621#bib.bib27)\], but usually stops at diagnosis\.AutoMemconnects these two directions by converting failed rollouts into module\-level textual feedback\. The feedback localizes memory\-related failures to Encode, Store, Retrieve, or Manage, and then guides architecture edits that are validated across search rounds\. This closes the loop from failure attribution to memory architecture improvement\.

Table 1:Representative memory systems decomposed along the four modules\(E,S,R,M\)\(E,S,R,M\), each mapped to the nearest atomic component in our menu \(Table[5](https://arxiv.org/html/2608.14621#A3.T5)\); the Manage column instead lists each system’s lifecycle operations, which the Manage presets in that menu bundle\. “–” marks a module a system does not implement \(e\.g\. no selective retrieval, or no lifecycle management\)\. Prior systems instantiate only a few components and leave the rest at generic defaults, whereasAutoMemsearches all four\.

## 3Preliminary Analysis

### 3\.1A Modular View of Agent Memory Architectures

Before introducingAutoMem, we first clarify what is being optimized when an LLM agent is equipped with long\-term memory\. Existing memory systems differ substantially in surface form: some store episodic trajectories, some distill verbal reflections, some maintain skill libraries or workflow memories, and others construct graph\-structured memories or curated knowledge bases\. Despite this diversity, their designs can be organized into four recurring architectural modules:Encode,Store,Retrieve, andManage\. We useℰ\\mathcal\{E\},𝒮\\mathcal\{S\},ℛ\\mathcal\{R\}, andℳ\\mathcal\{M\}to denote the candidate sets of these four modules, and use lowercasee∈ℰe\\in\\mathcal\{E\},s∈𝒮s\\in\\mathcal\{S\},r∈ℛr\\in\\mathcal\{R\}, andm∈ℳm\\in\\mathcal\{M\}to denote concrete module choices\.

Encodedetermines what information should be written into memory\. Common choices include task\-agnostic tips, failure\-derived insights, compressed action–observation trajectories, reusable workflows, and parameterized skills or shortcuts\. These choices reflect different assumptions about what kind of experience is reusable: natural\-language reflections emphasize general lessons, trajectory memories preserve concrete demonstrations, while workflow and skill memories aim to capture procedural knowledge\.

Storedetermines how encoded memories are represented\. Prior systems use plain textual buffers, key–value records, dense vector indices, hybrid symbolic–vector stores, entity–relation graphs, or LLM\-constructed temporal knowledge graphs\. The store format affects not only memory capacity, but also which retrieval and management operations are feasible\. For example, graph\-based retrieval requires a graph\-structured store, while embedding\-based retrieval is naturally paired with vectorized memory representations\.

Retrievedetermines how relevant memories are selected at inference time\. Existing approaches include semantic retrieval, lexical–semantic hybrid retrieval, contrastive retrieval over success and failure cases, case\-based reranking, graph traversal, hypothetical\-document embeddings, and diversity\-aware selection\. Retrieval is often treated as the central memory operation, but its effectiveness depends heavily on what has been encoded and how it has been stored\.

Managedetermines how the memory pool evolves over time\. Representative operations include forgetting, deduplication, conflict resolution, memory consolidation, trajectory\-to\-workflow promotion, and skill validation\. Management is especially important for long\-running agents, where stale, redundant, or conflicting memories can degrade performance even when retrieval itself is accurate\.

Under this modular view, a memory architecture is a tuplea=\(e,s,r,m\)a=\(e,s,r,m\), whereee,ss,rr, andmmare selected from the Encode, Store, Retrieve, and Manage candidate sets, respectively\. The unconstrained Cartesian space is𝒜~=ℰ×𝒮×ℛ×ℳ\\widetilde\{\\mathcal\{A\}\}=\\mathcal\{E\}\\times\\mathcal\{S\}\\times\\mathcal\{R\}\\times\\mathcal\{M\}\. In practice, not every tuple is valid because some modules impose compatibility constraints\. We therefore define the feasible memory architecture space as

𝒜=\{\(e,s,r,m\)∈𝒜~∣Valid⁡\(e,s,r,m\)=1\},\\mathcal\{A\}=\\\{\(e,s,r,m\)\\in\\widetilde\{\\mathcal\{A\}\}\\mid\\operatorname\{Valid\}\(e,s,r,m\)=1\\\},whereValid⁡\(⋅\)\\operatorname\{Valid\}\(\\cdot\)filters out incompatible module combinations, such as pairing a graph\-based retriever with a non\-graph store\. This definition separates module candidate sets from concrete memory architectures and ensures that every searched architecture is valid by construction\.

This four\-module formulation reveals that existing memory systems are not incomparable monoliths, but fixed points in a shared architectural space\. Table[1](https://arxiv.org/html/2608.14621#S2.T1)decomposes representative memory systems along Encode, Store, Retrieve, and Manage\. Two patterns emerge\. First, prior systems typically specialize in only one or two modules\. For example, skill\-library and workflow\-memory agents invest heavily inEncode, graph\-memory systems emphasizeStore, while memory banks and self\-updating memory systems focus more onManage\. Second, because most systems keep the remaining modules at generic defaults, they are difficult to adapt when failures originate outside their specialized component\. A failure caused by poor encoding cannot be solved by a stronger retriever alone; similarly, a useful memory representation may remain ineffective if retrieval or lifecycle management is mismatched\.

These observations motivate a shift from designing one fixed memory system to searching over memory architectures\. Rather than asking which existing memory method is universally best, we ask which feasible combinationa=\(e,s,r,m\)∈𝒜a=\(e,s,r,m\)\\in\\mathcal\{A\}is most suitable for a given task distribution and backbone model\.

### 3\.2Pilot Study: Why Memory Architecture Search Is Necessary

We conduct a preliminary random\-search study to examine whether the feasible architecture space𝒜\\mathcal\{A\}contains useful task\-specific memory architectures and whether blind search is sufficient to find them efficiently\. In this probe, we uniformly sample valid architecturesa∼Unif⁡\(𝒜\)a\\sim\\operatorname\{Unif\}\(\\mathcal\{A\}\)after filtering out incompatible module combinations\. Each sampled architecture is instantiated as an independent memory system and evaluated on the same task batches\. The score of one trial does not affect the next trial; no failure attribution, module\-level editing, or historical search memory is used\.

#### Finding 1: Strong memory architectures exist, but they are task\-specific\.

The random\-search probe shows that𝒜\\mathcal\{A\}contains architectures that can outperform strong fixed memory baselines\. For example, the best sampled architecture reaches69\.7%69\.7\\%on GAIA, improving over the strongest fixed memory baseline under the same backbone \(67\.8%67\.8\\%, MemoryBank\)\. This suggests that the architecture space is worth optimizing: fixed memory designs do not necessarily represent the ceiling of memory\-enhanced agent performance\. The same holds beyond GAIA: on xBench\-DeepSearch the best sampled architecture reaches46\.0%46\.0\\%, above the SOTA reference of45\.0%45\.0\\%\. Figure[1](https://arxiv.org/html/2608.14621#S3.F1)plots both benchmarks, showing that strong architectures exist on each, yet appear as scattered, dataset\-dependent peaks\.

![Refer to caption](https://arxiv.org/html/2608.14621v1/x1.png)

![Refer to caption](https://arxiv.org/html/2608.14621v1/x2.png)

Figure 1:Strong but scattered memory architectures exist on both benchmarks\.Each marker is one memory architecture sampled from the factored space, re\-evaluated on the full benchmark \(Qwen3\.5\-122B\-A10B; horizontal axis is a layout index\)\. On GAIA \(left\) and xBench\-DeepSearch \(right\), the best sample \(red\) exceeds the SOTA reference \(dashed line\):69\.769\.7vs\.67\.867\.8and46\.046\.0vs\.45\.045\.0\. The reference is the strongest same\-backbone fixed memory baseline \(MemoryBank\) on GAIA and the published SOTA on xBench\-DeepSearch\.However, the best architectures are not universal\. Across GAIA, WebWalkerQA, and xBench\-DeepSearch, the top configurations differ across all four modules\. For instance, one task may favor workflow\-style encoding with a hybrid store and semantic retrieval, whereas another may favor shortcut\-style encoding with a graph store and contrastive retrieval\. Moreover, a memory system that performs strongly on one benchmark can underperform the no\-memory baseline on another\. These results indicate that memory effectiveness depends on the interaction among task distribution, backbone model, and module composition\.

#### Finding 2: Module effects are coupled rather than additive\.

The pilot study also shows that individual module choices cannot be evaluated in isolation\. The contribution of an encodereedepends on whether the storesscan preserve its outputs in a retrievable form; the value of a retrieverrrdepends on whether the encoded memories are informative and whether the store supports the required retrieval operation; and the effect of a managermmdepends on the density, redundancy, and stability of the memory pool produced by the other modules\. A strong retriever may fail when the encoder writes low\-quality memories, a graph store may be ineffective without a compatible retrieval policy, and aggressive memory management can remove useful information when the encoded memory is sparse\. Thus, memory architecture quality is determined by cross\-module compatibility rather than by the independent quality of each module\.

#### Finding 3: Random search obtains SOTA results but wastes evaluation budget\.

Although random search can occasionally discover strong architectures, it cannot turn failed trials into reusable search signal\. Each candidateaarequires a costly agent rollout, yet the next candidate is sampled independently of previous successes and failures\. Increasing the sampling budget only increases the chance of accidentally landing on a good configuration; it does not make the search process more informed\. This limitation is especially problematic because the search landscape is scattered and task\-dependent, with strong architectures appearing as isolated peaks rather than as a smooth region\.

The preliminary analysis shows that strong memory architectures exist, but their effectiveness is task\-specific, module\-coupled, and difficult to discover through blind search\. This motivates a formal task definition: selecting a feasible memory architecturea∈𝒜a\\in\\mathcal\{A\}that best matches a given task distribution, backbone model, and evaluation budget\.

### 3\.3Definition: Task\-Adaptive Memory Architecture Selection

Based on the modular view above, we formulate memory design as a task\-adaptive architecture selection problem\. Let𝒟\\mathcal\{D\}denote a task distribution and letB=\{\(xi,yi\)\}i=1n∼𝒟B=\\\{\(x\_\{i\},y\_\{i\}\)\\\}\_\{i=1\}^\{n\}\\sim\\mathcal\{D\}denote an evaluation batch sampled from this distribution\. LetAaA\_\{a\}denote the backbone agent equipped with memory architecturea∈𝒜a\\in\\mathcal\{A\}, and letA0A\_\{0\}denote the same backbone agent without long\-term memory\. For a task inputxix\_\{i\}, the prediction made byAaA\_\{a\}is denoted asy^ia=Aa​\(xi\)\\hat\{y\}\_\{i\}^\{a\}=A\_\{a\}\(x\_\{i\}\)\. We evaluate a candidate architecture by its task accuracy:

Acc​\(Aa;B\)=1\|B\|​∑i=1\|B\|𝟏​\[y^ia=yi\]\.\\mathrm\{Acc\}\(A\_\{a\};B\)=\\frac\{1\}\{\|B\|\}\\sum\_\{i=1\}^\{\|B\|\}\\mathbf\{1\}\\left\[\\hat\{y\}\_\{i\}^\{a\}=y\_\{i\}\\right\]\.
In addition to absolute accuracy, we consider whether the selected architecture actually improves the backbone agent rather than merely inheriting its original capability\. We therefore define the memory\-induced gain of architectureaaon batchBBas

Δ​\(a;B\)=Acc​\(Aa;B\)−Acc​\(A0;B\)\.\\Delta\(a;B\)=\\mathrm\{Acc\}\(A\_\{a\};B\)\-\\mathrm\{Acc\}\(A\_\{0\};B\)\.A desirable memory architecture should achieve highAcc​\(Aa;B\)\\mathrm\{Acc\}\(A\_\{a\};B\), provide positive and stableΔ​\(a;B\)\\Delta\(a;B\), and avoid unnecessary inference cost\. When two architectures obtain comparable accuracy, we prefer the one with lower rollout cost, such as lower token consumption or fewer memory operations\.

Given a search budgetTT, the goal is to identify an architecture

a⋆∈arg⁡maxa∈𝒜⁡𝔼B∼𝒟​\[Acc​\(Aa;B\)\],s\.t\.Neval≤T,a^\{\\star\}\\in\\arg\\max\_\{a\\in\\mathcal\{A\}\}\\ \\mathbb\{E\}\_\{B\\sim\\mathcal\{D\}\}\\left\[\\mathrm\{Acc\}\(A\_\{a\};B\)\\right\],\\quad\\text\{s\.t\.\}\\quad N\_\{\\mathrm\{eval\}\}\\leq T,whereNevalN\_\{\\mathrm\{eval\}\}is the number of evaluated candidate architectures\. In practice, the expectation over𝒟\\mathcal\{D\}is estimated using held\-out task batches, and we report both task accuracy and memory\-induced gains overA0A\_\{0\}\.

This formulation clarifies the scope of our optimization\. We do not update the backbone model parameters, and we do not synthesize arbitrary memory implementations\. Instead, we search over a structured and feasible space𝒜\\mathcal\{A\}of memory architectures and select the combination of encoding, storage, retrieval, and management modules that best fits a given task distribution\. Since evaluating each candidate requires running the full agent, exhaustive search is expensive and random search provides limited reusable signal\. This motivatesAutoMem, which uses previous trials and failure analyses to guide memory architecture search under a limited evaluation budget\.

## 4Method

![Refer to caption](https://arxiv.org/html/2608.14621v1/x3.png)Figure 2:Overview ofAutoMem\.AutoMemperforms text\-gradient search over the factored memory architecture space𝒜=ℰ×𝒮×ℛ×ℳ\\mathcal\{A\}=\\mathcal\{E\}\\times\\mathcal\{S\}\\times\\mathcal\{R\}\\times\\mathcal\{M\}\(left lattice: Encode, Store, Retrieve, and Manage options; the two highlighted paths are two candidate architectures\)\.Top—Experience\-Guided Architecture Search \(EGAS, §[4\.2](https://arxiv.org/html/2608.14621#S4.SS2)\):a proposer LLM conditions on the Pareto frontPtP\_\{t\}, the observation graph𝒢\\mathcal\{G\}, the experience ledgerℒ\\mathcal\{L\}, and the latest textual gradientδt\\delta\_\{t\}to proposeKKfeasible candidate architectures\.Bottom—Failure\-Guided Module Diagnosis \(FGMD, §[4\.3](https://arxiv.org/html/2608.14621#S4.SS3)\):candidates are evaluated on the search batchBsB\_\{s\}, producing rollout traces and updating the Pareto front; a rule\-based scope gate discards memory\-unrelated failures \(e\.g\., tool errors, timeouts\), and the remaining failures are attributed to the responsible module, yielding the textual gradientδt\+1\\delta\_\{t\+1\}that steers the next round\.### 4\.1Overview

We proposeAutoMem, a text\-gradient recursive self\-improvement framework for the task\-adaptive memory architecture selection problem of §[3\.3](https://arxiv.org/html/2608.14621#S3.SS3): within an evaluation budgetTT, find the feasible architecturea=\(e,s,r,m\)∈𝒜a=\(e,s,r,m\)\\in\\mathcal\{A\}\(§[3\.1](https://arxiv.org/html/2608.14621#S3.SS1)\) that maximizes task accuracyAcc​\(Aa;B\)\\mathrm\{Acc\}\(A\_\{a\};B\)while providing positive memory\-induced gainΔ​\(a;B\)\\Delta\(a;B\)over the no\-memory agentA0A\_\{0\}\.AutoMeminstantiates the expectation over𝒟\\mathcal\{D\}with three disjoint batches—a search batchBsB\_\{s\}on which candidates are evaluated, a validation batchBvB\_\{v\}on which the current best architecture must confirm its gain before being accepted, and a held\-out test batchBtB\_\{t\}for final reporting—and ranks candidates by a Pareto objective over task accuracy, memory\-induced gain, and rollout cost\.

The key challenge is that𝒜\\mathcal\{A\}is discrete, module\-coupled, and observable only through full agent rollouts\. Therefore,AutoMemdoes not rely on analytic gradients\. Instead, it constructs a textual optimization signal from failed rollouts\. Each round contains two components, as illustrated in Figure[2](https://arxiv.org/html/2608.14621#S4.F2)\. First, Experience\-Guided Architecture Search \(EGAS\) proposes candidate architectures by conditioning a proposer LLM on historical search experience, current Pareto\-optimal architectures, and the latest diagnostic feedback\. Second, Failure\-Guided Module Diagnosis \(FGMD\) analyzes unsuccessful rollouts, localizes failures to one of the four memory modules, and converts the evidence into module\-level textual feedback for the next round\.

Concretely,AutoMemfirst evaluates the no\-memory baseline and initializes two search memories: an experience ledgerℒ\\mathcal\{L\}and an observation graph𝒢\\mathcal\{G\}\. At roundtt, EGAS proposesKKfeasible architectures\{at\(k\)\}k=1K\\\{a\_\{t\}^\{\(k\)\}\\\}\_\{k=1\}^\{K\}\. Each candidate is evaluated onBsB\_\{s\}, producing task accuracy, memory\-induced gain, cost, and rollout traces\. The Pareto frontPtP\_\{t\}is then updated\. FGMD analyzes failed traces from the round and produces a textual gradientδt\+1\\delta\_\{t\+1\}, which summarizes the dominant module bottleneck and recommends targeted architecture edits\. The loop repeats forNNrounds, and the final architecture is selected by validation performance onBvB\_\{v\}and reported on the held\-out test batchBtB\_\{t\}\. Algorithm[1](https://arxiv.org/html/2608.14621#alg1)summarizes the overall procedure, and Appendix[B](https://arxiv.org/html/2608.14621#A2)traces one optimization round of this loop with verbatim runtime artifacts\.

Algorithm 1AutoMem: Text\-gradient search over memory architectures\.1:Feasible architecture space

𝒜\\mathcal\{A\}; search, validation, and test batches

Bs,Bv,BtB\_\{s\},B\_\{v\},B\_\{t\}; rounds

NN; candidates per round

KK; validation period

τ\\tau\.

2:Evaluate the no\-memory agent

A0A\_\{0\}on

Bs∪BvB\_\{s\}\\cup B\_\{v\}\.

3:Initialize experience ledger

ℒ\\mathcal\{L\}, observation graph

𝒢\\mathcal\{G\}, Pareto front

P0←∅P\_\{0\}\\leftarrow\\emptyset, and textual feedback

δ1←∅\\delta\_\{1\}\\leftarrow\\emptyset\.

4:for

t=1t=1to

NNdo

5:

\{at\(1\),…,at\(K\)\}←EGAS​\(δt,ℒ,𝒢,Pt−1\)\\\{a\_\{t\}^\{\(1\)\},\\ldots,a\_\{t\}^\{\(K\)\}\\\}\\leftarrow\\textsc\{EGAS\}\(\\delta\_\{t\},\\mathcal\{L\},\\mathcal\{G\},P\_\{t\-1\}\)\.

6:for

k=1k=1to

KKin paralleldo

7:Run agent

Aat\(k\)A\_\{a\_\{t\}^\{\(k\)\}\}on

BsB\_\{s\}and record accuracy, gain, cost, and rollout traces\.

8:endfor

9:Update

PtP\_\{t\}using non\-dominated candidates under accuracy, gain, and cost\.

10:if

tmodτ=0t\\bmod\\tau=0then

11:Validate the current Pareto\-front leader on

BvB\_\{v\}\.

12:endif

13:

δt\+1←FGMD​\(\{failed rollouts of​at\(k\)\}k=1K\)\\delta\_\{t\+1\}\\leftarrow\\textsc\{FGMD\}\(\\\{\\text\{failed rollouts of \}a\_\{t\}^\{\(k\)\}\\\}\_\{k=1\}^\{K\}\)\.

14:Update

ℒ\\mathcal\{L\}and

𝒢\\mathcal\{G\}with round\-level outcomes and module\-level evidence\.

15:endfor

16:returnthe validated Pareto\-front leader

a⋆a^\{\\star\}, evaluated on

BtB\_\{t\}\.

### 4\.2Experience\-Guided Architecture Search

Experience\-Guided Architecture Search proposes feasible memory architectures by using accumulated search evidence as a structured prior\. A naive proposer that only uses the latest diagnostic feedback may repeatedly explore already failed edits or overfit to a small set of recent trajectories\. EGAS addresses this by conditioning candidate generation on three forms of search state: the Pareto frontPtP\_\{t\}, the experience ledgerℒ\\mathcal\{L\}, and the observation graph𝒢\\mathcal\{G\}\.

#### Candidate proposal\.

At roundtt, EGAS receives the latest textual feedbackδt\\delta\_\{t\}and proposesKKarchitectures:

\{at\(1\),…,at\(K\)\}=Proposeθ​\(δt,ℒt,𝒢t,Pt\),\\\{a\_\{t\}^\{\(1\)\},\\ldots,a\_\{t\}^\{\(K\)\}\\\}=\\mathrm\{Propose\}\_\{\\theta\}\\left\(\\delta\_\{t\},\\mathcal\{L\}\_\{t\},\\mathcal\{G\}\_\{t\},P\_\{t\}\\right\),whereProposeθ\\mathrm\{Propose\}\_\{\\theta\}is an LLM\-based proposer\. Each proposal is a tuplea=\(e,s,r,m\)a=\(e,s,r,m\)rather than a regenerated memory implementation\. This design keeps the search controlled: one proposal changes named coordinates in the architecture space while preserving validity constraints\. We enforce validity with a deterministic checker:

at\(k\)∈𝒜⟺Valid⁡\(et\(k\),st\(k\),rt\(k\),mt\(k\)\)=1\.a\_\{t\}^\{\(k\)\}\\in\\mathcal\{A\}\\quad\\Longleftrightarrow\\quad\\operatorname\{Valid\}\(e\_\{t\}^\{\(k\)\},s\_\{t\}^\{\(k\)\},r\_\{t\}^\{\(k\)\},m\_\{t\}^\{\(k\)\}\)=1\.Invalid proposals are rejected and resampled before evaluation\. A verbatim proposal, together with the diagnostic evidence it cites, is shown in Appendix[B\.1](https://arxiv.org/html/2608.14621#A2.SS1)\.

#### Experience ledger\.

The ledgerℒ\\mathcal\{L\}stores reusable cross\-round search knowledge\. Each entry is represented as

ℓ=\(c,u,q,z\),\\ell=\(c,\\ u,\\ q,\\ z\),whereccis the condition under which the entry applies,uuis a recommended or discouraged edit,qqis supporting evidence, andzzis the status of the entry \(*active*,*pending*, or*refuted*\)\. For example, if repeated trials show that graph retrieval underperforms when the memory pool is sparse, the ledger records this as a discouraged Retrieve–Store edit under sparse\-memory conditions\. During proposal, active entries bias the LLM toward edits with positive evidence, while refuted or dead\-end entries prevent repeated exploration of previously unproductive directions\. Appendix[B\.3](https://arxiv.org/html/2608.14621#A2.SS3)shows verbatim ledger entries, including a principle refuted by differential validation\.

#### Observation graph\.

The observation graph𝒢\\mathcal\{G\}stores task\-pattern\-level statistics about which module choices have worked in previous rounds\. Nodes correspond to task patterns, module choices, and observed outcomes; edges record empirical associations between them\. For a task patternccand a module choiceuu, EGAS maintains running statistics such as

μ​\(c,u\)=1n​\(c,u\)​∑j:cj=c,uj=uΔ​\(aj;Bj\),\\mu\(c,u\)=\\frac\{1\}\{n\(c,u\)\}\\sum\_\{j:\\,c\_\{j\}=c,\\,u\_\{j\}=u\}\\Delta\(a\_\{j\};B\_\{j\}\),wheren​\(c,u\)n\(c,u\)is the number of evaluated architectures containing choiceuuunder conditioncc\. These statistics are used as soft priors rather than hard rules\. This is especially useful for the Encode module, since encoding failures are often under\-observed: a missing memory is harder to attribute than an incorrectly retrieved one\. An excerpt of𝒢\\mathcal\{G\}is shown in Appendix[B\.4](https://arxiv.org/html/2608.14621#A2.SS4)\.

#### Pareto\-based acceptance\.

After evaluating all proposed candidates, EGAS updates a Pareto front over accuracy, memory\-induced gain, and cost\. A candidateaia\_\{i\}dominatesaja\_\{j\}if it is no worse on all objectives and strictly better on at least one:

ai≻aj⟺Acci≥Accj,Δi≥Δj,Costi≤Costj,a\_\{i\}\\succ a\_\{j\}\\quad\\Longleftrightarrow\\quad\\mathrm\{Acc\}\_\{i\}\\geq\\mathrm\{Acc\}\_\{j\},\\ \\Delta\_\{i\}\\geq\\Delta\_\{j\},\\ \\mathrm\{Cost\}\_\{i\}\\leq\\mathrm\{Cost\}\_\{j\},with at least one strict inequality\. The updated front is

Pt\+1=\{a∈Pt∪\{at\(k\)\}k=1K∣∄​a′∈Pt∪\{at\(k\)\}k=1K​such that​a′≻a\}\.P\_\{t\+1\}=\\left\\\{a\\in P\_\{t\}\\cup\\\{a\_\{t\}^\{\(k\)\}\\\}\_\{k=1\}^\{K\}\\mid\\nexists a^\{\\prime\}\\in P\_\{t\}\\cup\\\{a\_\{t\}^\{\(k\)\}\\\}\_\{k=1\}^\{K\}\\text\{ such that \}a^\{\\prime\}\\succ a\\right\\\}\.The front leader is periodically re\-evaluated on validation data to reduce search batch overfitting\. Only validated improvements are promoted as reliable experience inℒ\\mathcal\{L\}and𝒢\\mathcal\{G\}\.

### 4\.3Failure\-Guided Module Diagnosis

Failure\-Guided Module Diagnosis converts failed rollouts into a module\-level textual gradient\. Given failed trajectories from the current round, FGMD answers three questions: whether the failure is memory\-attributable, which module is most likely responsible, and what architecture edit should be attempted next\.

#### Scope filtering\.

Not every failed rollout should update the memory architecture\. Some failures are caused by tool errors, timeouts, unavailable web pages, evaluator ambiguity, or reasoning mistakes unrelated to memory\. FGMD first applies a rule\-based scope gate to remove such out\-of\-scope cases\. A failure is considered memory\-attributable only if the trace contains evidence that memory could plausibly have changed the outcome, such as missing reusable information, irrelevant retrieved memory, stale memory, or conflicting memory entries\.

Formally, for each failed trajectoryτi\\tau\_\{i\}, the scope gate assigns

gi=Scope⁡\(τi\)∈\{0,1\},g\_\{i\}=\\operatorname\{Scope\}\(\\tau\_\{i\}\)\\in\\\{0,1\\\},wheregi=1g\_\{i\}=1indicates an in\-scope memory\-related failure\. Only trajectories withgi=1g\_\{i\}=1are passed to module attribution\.

#### Module attribution\.

FGMD first applies a rule\-based classifier that assigns each in\-scope failure a dominant failure mode from memory\-trace signals—whether relevant units exist in the pool, whether they were retrieved, whether a consistency judge kept or dropped them, and whether kept units were stale:

fi=Classify⁡\(τi\)∈ℱ\.f\_\{i\}=\\operatorname\{Classify\}\(\\tau\_\{i\}\)\\in\\mathcal\{F\}\.Hereℱ\\mathcal\{F\}collects memory\-failure modes such as extraction gap, low\-quality extraction, retrieval miss, judge\-rejected retrieval, retrieval noise, and stale memory, and a fixed table maps each mode to the responsible modulebi∈\{E,S,R,M\}b\_\{i\}\\in\\\{E,S,R,M\\\}\. A failure maps to Encode \(EE\) when useful information from previous experience was never extracted or was compressed into an unusable form; to Store \(SS\) when the information was encoded but represented in a format that prevents effective access, indexing, or cross\-memory linking; to Retrieve \(RR\) when relevant memories exist but are not retrieved, are ranked below irrelevant entries, or are poorly injected into the agent context; and to Manage \(MM\) when the memory pool contains stale, duplicated, contradictory, or low\-value entries that interfere with current decision making\. Failures that resist rule attribution—retrieval and the consistency judge both pass yet the answer is still wrong—are further examined by the diagnosis LLM, which reads up to a fixed number of such traces \(sampling when more exist\), inspects each one \(its question, gold and agent answers, and final steps\), and relabels recognizable non\-memory failures \(numeric, format, or time\-window errors\) as out of scope, sharpening the per\-module histogram\.

#### Aggregation\.

Single\-trajectory diagnoses are noisy, so FGMD aggregates the per\-task modes across the round\. Mapping each modefif\_\{i\}to its module yields the per\-module failure histogram

Ht​\(q\)=∑i𝟏​\[gi=1\]​1​\[bi=q\],q∈\{E,S,R,M\}\.H\_\{t\}\(q\)=\\sum\_\{i\}\\mathbf\{1\}\[g\_\{i\}=1\]\\,\\mathbf\{1\}\[b\_\{i\}=q\],\\qquad q\\in\\\{E,S,R,M\\\}\.The histogram nominates a candidate bottleneck, but FGMD fixes the primary bottleneckqt⋆q\_\{t\}^\{\\star\}with an LLM diagnostician that reads the histogram together with representative failed trajectories and emits a per\-module diagnosis\. When the histogram and the diagnostician disagree, FGMD adopts the diagnostician’s module and records the disagreement\. FGMD then samples representative trajectories forqt⋆q\_\{t\}^\{\\star\}as grounded evidence, which prevents a single anomalous failure from dominating the next search step\.

#### Textual gradient synthesis\.

Finally, an LLM\-based synthesizer consolidates the round’s diagnostic signals—the per\-module failure histogram, the per\-module diagnosis, and the grounded evidence—into a structured textual gradient:

δt\+1=\(qt⋆,ℰt,ρt,ℛt\),\\delta\_\{t\+1\}=\\left\(q\_\{t\}^\{\\star\},\\ \\mathcal\{E\}\_\{t\},\\ \\rho\_\{t\},\\ \\mathcal\{R\}\_\{t\}\\right\),whereqt⋆q\_\{t\}^\{\\star\}is the primary module bottleneck,ℰt\\mathcal\{E\}\_\{t\}is the grounded evidence \(representative failed\-task identifiers\),ρt\\rho\_\{t\}is a categorical confidence level \(high, medium, or low\), andℛt\\mathcal\{R\}\_\{t\}is a recommended architecture edit constrained to the valid edits of the search space\. For example, a Retrieve bottleneck may recommend switching from pure semantic retrieval to hybrid retrieval or adding diversity\-aware reranking, whereas a Manage bottleneck may recommend deduplication, conflict resolution, or more conservative forgetting\. The synthesized object also carries an out\-of\-scope flag that realizes the scope filtering above and a cross\-source\-agreement field that records whether the rule\-based histogram and the LLM diagnosis agree onqt⋆q\_\{t\}^\{\\star\}\. Appendix[B\.2](https://arxiv.org/html/2608.14621#A2.SS2)shows a complete synthesized gradient produced during search\.

#### Differential validation\.

To avoid repeatedly following an unhelpful diagnostic direction, FGMD compares the current round with the previous round\. If the last edit targeted moduleqqbut did not improve accuracy, memory\-induced gain, or validation performance, the corresponding recommendation is downgraded inℒ\\mathcal\{L\}\. If it improves the Pareto front or validation leader, the recommendation is promoted as an active principle\. This closes the loop between failure attribution and architecture search: diagnosis proposes a module\-level direction, EGAS tests it through candidate architectures, and validation determines whether the direction should be retained or refuted\.

## 5Experiments

### 5\.1Experimental Setup

Datasets and Metrics\.We evaluate our method on three challenging agentic search and reasoning benchmarks: GAIA, WebWalkerQA, and xBench\-DeepSearch\. GAIA provides three difficulty levels, L1/L2/L3, and is therefore used for difficulty\-stratified analysis\[[31](https://arxiv.org/html/2608.14621#bib.bib31)\]\. WebWalkerQA evaluates deep web navigation and multi\-step information seeking\[[32](https://arxiv.org/html/2608.14621#bib.bib32)\]\. xBench\-DeepSearch contains 100 Chinese deep\-search questions and serves as a hard external robustness check\[[33](https://arxiv.org/html/2608.14621#bib.bib33)\]\. Since xBench\-DeepSearch does not provide difficulty labels, all difficulty\-based analysis is conducted on GAIA\. We evaluate performance using accuracy, memory lift, token cost, latency, number of reasoning steps, retrieval hit\-rate, and regression rate, following the definitions in §[3\.3](https://arxiv.org/html/2608.14621#S3.SS3)\.

Baselines\.We compare our method with a No\-Memory baseline and a representative set of memory\-based agent systems\. These baselines cover major paradigms in agent memory research, including episodic and long\-term memory methods, such as Generative Agents\[[2](https://arxiv.org/html/2608.14621#bib.bib2)\], Mem0\[[4](https://arxiv.org/html/2608.14621#bib.bib4)\], and MemoryBank\[[29](https://arxiv.org/html/2608.14621#bib.bib29)\]; experiential and reflective memory methods, represented by ExpeL\[[7](https://arxiv.org/html/2608.14621#bib.bib7)\]and DiLu\[[34](https://arxiv.org/html/2608.14621#bib.bib34)\]; procedural and skill memory methods, including Voyager\[[8](https://arxiv.org/html/2608.14621#bib.bib8)\], Agent Workflow Memory\[[9](https://arxiv.org/html/2608.14621#bib.bib9)\], Agent\-KB\[[12](https://arxiv.org/html/2608.14621#bib.bib12)\], Dynamic Cheatsheet\[[11](https://arxiv.org/html/2608.14621#bib.bib11)\], and Memp\[[30](https://arxiv.org/html/2608.14621#bib.bib30)\]; as well as self\-evolving memory systems MemEvolve\[[14](https://arxiv.org/html/2608.14621#bib.bib14)\]and Mobile\-Agent\-E\[[35](https://arxiv.org/html/2608.14621#bib.bib35)\]\. This comparison provides broad coverage of existing memory designs for LLM agents\.

Implementation Details\.For the task agent, we use Qwen3\.5\-122B\-A10B and gpt\-5\.1\-mini as backbone models, implemented on top of a DAG\-based parallel web\-agent framework\[[36](https://arxiv.org/html/2608.14621#bib.bib36)\]\. To avoid overfitting during memory architecture search, we split the data into three disjoint parts: the search split is used to evaluate candidate memory architectures and update𝒢\\mathcal\{G\}andℒ\\mathcal\{L\}; the held\-out validation split is used to select the Pareto leader and perform round\-over\-round improvement checks; and the test split is used only for final reported results\. In each search round, the Meta\-LLM proposesK=3K\{=\}3candidate memory architectures, and the search runs for a small number of rounds per benchmark; the full search budgets are reported in Appendix Table[6](https://arxiv.org/html/2608.14621#A5.T6)\.

Table 2:Main results:AutoMemvs\. existing memory architectures on the shared benchmark suite\.Perf\.is accuracy \(%,↑\\uparrow\);Costis mean tokens/task in thousands \(k\),Delay\(s\), and\#Stepsare↓\\downarrow\(mean values\)\. Rows are grouped by task\-agent backbone; within each group the final row is the architectureAutoMemdiscovers \(its accuracy shown inbold\)\.Memory SettingGAIAxBenchWebWalkerQAPerf\.CostDelay\#StepsPerf\.CostDelay\#StepsPerf\.CostDelay\#StepsBackbone: Qwen3\.5\-122B\-A10BNo\-Memory65\.0335\.566113\.130\.0412\.643314\.067\.6111\.73097\.3Mem0\[[4](https://arxiv.org/html/2608.14621#bib.bib4)\]67\.1215\.73659\.736\.0434\.462114\.366\.5131\.13837\.0MemoryBank\[[29](https://arxiv.org/html/2608.14621#bib.bib29)\]67\.8200\.43029\.545\.0430\.253514\.967\.1111\.82836\.6ExpeL\[[7](https://arxiv.org/html/2608.14621#bib.bib7)\]63\.6204\.03299\.744\.0351\.739512\.967\.1114\.22267\.1Voyager\[[8](https://arxiv.org/html/2608.14621#bib.bib8)\]66\.4235\.735811\.040\.0383\.642513\.866\.9130\.02608\.0Agent\-KB\[[12](https://arxiv.org/html/2608.14621#bib.bib12)\]64\.3221\.642210\.040\.0338\.845812\.468\.9119\.63046\.9Memp\[[30](https://arxiv.org/html/2608.14621#bib.bib30)\]66\.4199\.13169\.841\.0332\.434512\.566\.5104\.52156\.7AutoMem\(ours\)71\.5128\.42706\.046\.0395\.772915\.672\.5118\.71826\.4Backbone: gpt\-5\.1\-miniNo\-Memory69\.186\.050510\.469\.0141\.052314\.771\.248\.02526\.9Generative Agents\[[2](https://arxiv.org/html/2608.14621#bib.bib2)\]66\.761\.04368\.970\.0131\.081813\.572\.445\.02696\.6Voyager\[[8](https://arxiv.org/html/2608.14621#bib.bib8)\]69\.760\.05009\.368\.0117\.055312\.773\.549\.03347\.0DiLu\[[34](https://arxiv.org/html/2608.14621#bib.bib34)\]66\.759\.04458\.969\.0134\.050113\.872\.946\.02727\.0ExpeL\[[7](https://arxiv.org/html/2608.14621#bib.bib7)\]66\.159\.05008\.764\.0123\.071013\.169\.476\.038511\.0Agent Workflow Memory\[[9](https://arxiv.org/html/2608.14621#bib.bib9)\]67\.362\.058510\.271\.0138\.076114\.172\.468\.039711\.4Mobile\-Agent\-E\[[35](https://arxiv.org/html/2608.14621#bib.bib35)\]69\.165\.03229\.468\.0120\.053713\.271\.859\.02966\.5Dynamic Cheatsheet\[[11](https://arxiv.org/html/2608.14621#bib.bib11)\]68\.569\.05609\.765\.0174\.081816\.072\.957\.03677\.6MemEvolve\[[14](https://arxiv.org/html/2608.14621#bib.bib14)\]73\.385\.069310\.174\.0136\.077314\.274\.740\.03326\.6AutoMem\(ours\)75\.2103\.483213\.179\.0243\.487211\.376\.576\.675010\.8Backbone: gpt\-5\.4AutoMem\(ours\)77\.698\.160611\.284\.01164028\.379\.487\.91517\.4
### 5\.2Main Results

Table[2](https://arxiv.org/html/2608.14621#S5.T2)comparesAutoMemwith representative manually designed memory mechanisms under two task\-agent backbones\. To avoid conflating memory design with backbone capacity, we compare methods within each backbone group\. Under Qwen3\.5\-122B\-A10B, the architecture discovered byAutoMemachieves the best accuracy on all three benchmarks, reaching71\.5%71\.5\\%on GAIA,46\.0%46\.0\\%on xBench, and72\.5%72\.5\\%on WebWalkerQA\. Compared with the strongest manually designed baseline on each benchmark,AutoMemimproves accuracy by\+3\.7\+3\.7,\+1\.0\+1\.0, and\+3\.6\+3\.6points, respectively\. The same trend holds under gpt\-5\.1\-mini, whereAutoMemfurther improves over the strongest baseline by\+1\.9\+1\.9,\+5\.0\+5\.0, and\+1\.8\+1\.8points on the three benchmarks\. These consistent gains across both backbones show thatAutoMemdiscovers task\-adaptive memory architectures that are stronger than fixed human\-designed memory mechanisms\.

The gains are not simply obtained by blindly increasing memory usage or interaction length\. Under Qwen3\.5\-122B\-A10B,AutoMemsubstantially reduces token cost, delay, and average steps on GAIA, and achieves the lowest delay and fewest steps on WebWalkerQA while maintaining the best accuracy\. On xBench, it also improves accuracy over all baselines while using fewer tokens than the closest accuracy competitor, MemoryBank, although the deeper search process leads to higher delay and more steps\. In contrast, manually designed memory mechanisms are highly task\-sensitive: MemoryBank performs strongly on xBench but brings limited gains on WebWalkerQA, while Agent\-KB performs well on WebWalkerQA but falls below the No\-Memory baseline on GAIA\. These results suggest that different tasks require different memory designs, and that searching task\-adaptive Encode/Store/Retrieve/Manage architectures provides a more robust accuracy\-efficiency trade\-off than relying on a single hand\-crafted memory mechanism\.

![Refer to caption](https://arxiv.org/html/2608.14621v1/x4.png)Figure 3:AutoMemevolution vs\. random search on GAIA \(Qwen3\.5\-122B\-A10B\)\.Left:ten architectures sampled by random search \(gray bars\), most below the No\-Memory baseline \(dashed, 65\.0\) and the best reaching 69\.7\.Right:AutoMem’s best\-so\-far accuracy over rounds, improving monotonically to 71\.5 and surpassing the best random sample within fewer evaluations\.
### 5\.3Guided Search vs\. Random Search

A natural question is whether the failure\-guided evolution inAutoMemis genuinely more effective than blindly sampling architectures from the same factored space\. Figure[3](https://arxiv.org/html/2608.14621#S5.F3)comparesAutoMemwith random search under the same evaluation setting\. The results show three clear observations\. First,AutoMemis substantially more search\-efficient: after only five evolution rounds, it reaches71\.5%71\.5\\%accuracy, already surpassing the best result obtained by ten random trials \(69\.7%69\.7\\%\)\. This indicates thatAutoMemcan identify stronger memory architectures with roughly half the search budget\. Second, the performance ofAutoMemimproves steadily across iterations, increasing from55\.8%55\.8\\%in the first round to64\.2%64\.2\\%,67\.9%67\.9\\%, and finally71\.5%71\.5\\%\. This monotonic improvement suggests that the accumulated reflections and failure\-guided feedback provide useful directional signals for architecture refinement\. Third, random search is highly unstable: its performance fluctuates substantially across trials, and most sampled architectures even perform worse than the No\-Memory baseline \(65\.0%65\.0\\%\)\. These results demonstrate that the gains ofAutoMemcome from directed, feedback\-driven search rather than from simply sampling more candidate architectures\.

#### Token cost\.

Table[3](https://arxiv.org/html/2608.14621#S5.T3)complements Figure[3](https://arxiv.org/html/2608.14621#S5.F3)by reporting what each search protocol costs in task\-agent rollout tokens\. One fullAutoMemevolution run—including the no\-memory baseline evaluation, warm\-up, and held\-out validation—consumes142\.7142\.7M tokens on GAIA and160\.1160\.1M on xBench\-DeepSearch, whereas scoring the ten sampled architectures on the full benchmarks costs259\.0259\.0M and339\.0339\.0M:AutoMemcompletes its entire directed search for0\.55×0\.55\\timesand0\.47×0\.47\\timesthe token budget of random search\. Cheaper small\-batch scoring does not rescue random search: its batch\-selected champion overfits the search batch and drops to63\.0%63\.0\\%on the full GAIA set, below the No\-Memory baseline \(Table[4](https://arxiv.org/html/2608.14621#S5.T4)\), so reliable selection forces random search to re\-evaluate every sample at full scale\.AutoMeminstead converts each failed rollout into reusable feedback, reaching a stronger architecture \(71\.571\.5vs\.69\.769\.7\) at roughly half the token cost\.

Table 3:Search\-stage token cost ofAutoMemvs\. random search \(task\-agent rollout tokens, in millions; Qwen3\.5\-122B\-A10B backbone\)\.AutoMemcovers one full evolution run \(no\-memory baseline, warm\-up, all search rounds, and held\-out validation\); random search covers evaluating the ten architectures sampled in §[3](https://arxiv.org/html/2608.14621#S3)on the full benchmark\. Meta\-LLM proposal and diagnosis calls are excluded \(a few calls per round, negligible relative to rollouts\)\. The random\-search totals reuse cached search\-batch rollouts where available, and one xBench architecture terminated early \(56/100 tasks\), so they are lower bounds\.Table 4:Component ablation on GAIA\.

### 5\.4Ablation Study

AutoMemconsists of two components: Failure\-Guided Module Diagnosis \(FGMD\), which turns failed rollouts into module\-level textual feedback, and Experience\-Guided Architecture Search \(EGAS\), which proposes candidates from accumulated search experience\. Table[4](https://arxiv.org/html/2608.14621#S5.T4)ablates both components on GAIA\. Removing FGMD replaces structured module diagnosis with a generic “some tasks failed” signal while preserving the experienced proposer\. Removing EGAS makes the proposer memoryless, allowing it to see only the current architecture and latest diagnosis, without the ledger, reflections, or accumulated search history\. Removing both reduces the method to random search\.

The results show that both components are necessary\. Without FGMD, the discovered architecture drops to64\.2%64\.2\\%accuracy with a−0\.8\-0\.8memory lift, falling below the No\-Memory baseline, while token cost nearly doubles from128\.4128\.4k to226\.7226\.7k\. This suggests that, without module\-level attribution, the search is easily steered toward costly but ineffective architectures\. Removing EGAS is even more damaging, reducing accuracy to57\.9%57\.9\\%with a−7\.1\-7\.1memory lift and the highest token cost among all variants \(297\.3297\.3k\)\. Without the ledger and observation graph, the proposer cannot accumulate reliable search experience: its per\-round best score on the search batch decays from0\.700\.70to0\.680\.68,0\.660\.66, and0\.660\.66, later rounds re\-propose near\-identical configurations, and harmful design choices are repeatedly explored\. Moreover, the round\-1 champion overfits the 50\-task search batch, scoring0\.700\.70there but falling below the No\-Memory baseline on the full set\. These two failure modes are complementary: w/o FGMD lacks directional failure attribution, whereas w/o EGAS cannot accumulate and trust useful directions\. This supports the text\-gradient view in §[4](https://arxiv.org/html/2608.14621#S4), where FGMD provides the gradient signal and EGAS provides the update memory\. Finally, removing both yields only63\.0%63\.0\\%accuracy with a−2\.0\-2\.0lift after four random sampling rounds, confirming that the gains ofAutoMemcome from directed search rather than from drawing more candidates\.

![Refer to caption](https://arxiv.org/html/2608.14621v1/x5.png)Figure 4:Architectures discovered byAutoMemper benchmark\. For each benchmark we show its task profile, the discovered Encode/Store/Retrieve/Manage route, and why that route fits the task distribution\.
### 5\.5Discovered Architectures

Finally, Figure[4](https://arxiv.org/html/2608.14621#S5.F4)visualizes the final Encode/Store/Retrieve/Manage paths discovered byAutoMemon each benchmark, together with the corresponding task profile and the rationale behind each route\. Although all architectures are searched from the same factored component menu,AutoMemconverges to clearly different memory designs across task distributions\. On GAIA, where tasks involve multi\-step web reasoning, cross\-page entity linking, and reusable tool traces,AutoMemselects*Tip\+Workflow\+Trajectory*encoding, a graph store, contrastive retrieval, and lightweight management\. This route preserves successful tool\-use trajectories, organizes entities and actions relationally, and uses contrastive retrieval to distinguish useful experiences from failed ones\. On WebWalkerQA, which emphasizes web\-navigation question answering, exact evidence grounding, and repeated browsing patterns, the discovered route uses*Insight\+Workflow\+Shortcut*encoding, aJSONstore, hybrid retrieval, and tool\-manager based management\. This design captures reusable navigation procedures, keeps exact page\-level facts inspectable, and validates tool use during evidence collection\. On xBench\-DS, which requires deep search, long\-horizon exploration, and reuse of solved cases,AutoMemselects*Tip\+Insight\+Trajectory*encoding, aJSONstore, case\-based reranking, and lightweight management, enabling the agent to reuse prior solution traces while keeping retrieval efficient\.

These discovered routes provide qualitative evidence for the central claim ofAutoMem: memory architecture should adapt to the task distribution rather than remain fixed\. Different benchmarks favor different combinations of what to encode, how to store it, how to retrieve it, and how to manage it\. In particular, GAIA benefits from relational graph organization, WebWalkerQA favors structured factual storage and tool validation, while xBench\-DS relies more on case reuse and reranking for deep\-search reasoning\. The diversity of these E/S/R/M paths explains why manually designed memory mechanisms can be highly task\-sensitive, and further supports treating long\-term memory design as a task\-adaptive architecture search problem\.

## 6Conclusion

In this paper, we study long\-term memory design for LLM agents as a task\-adaptive architecture search problem\. We factorize agent memory into Encode, Store, Retrieve, and Manage modules, and show that fixed human\-designed memory architectures are highly sensitive to task distributions and backbone models, with no single design consistently dominating across benchmarks\. To address this challenge, we proposeAutoMem, a text\-gradient recursive self\-improvement framework that combines Experience\-Guided Architecture Search with Failure\-Guided Module Diagnosis\. By converting failed rollouts into module\-level textual feedback and accumulating search experience across iterations,AutoMemefficiently discovers stronger memory architectures under limited evaluation budgets\. Experiments on GAIA, WebWalkerQA, and xBench\-DeepSearch demonstrate that the discovered architectures outperform existing memory baselines while improving the accuracy\-efficiency trade\-off, and ablation studies confirm that both failure\-guided diagnosis and experience\-guided search are essential\. Overall, our results suggest that memory for LLM agents should not be treated as a fixed hand\-crafted mechanism, but as an adaptive architecture that can be optimized according to the target task distribution\.

## 7Limitations and Future Work

This work takes a first step toward task\-adaptive memory architecture search, but several directions remain open for future exploration\. First,AutoMemcurrently searches memory architectures at the task or benchmark level, where one discovered Encode/Store/Retrieve/Manage path is used for all samples from the same task distribution\. This design is effective and efficient when tasks share similar memory requirements, but individual samples may still differ in their need for memory granularity, retrieval depth, or management strategy\. A promising direction is to extendAutoMemfrom task\-level architecture search to sample\-level or episode\-level memory adaptation, where the agent dynamically selects or routes memory modules according to the current query, interaction history, and observed failure signals\.

Second, the current search space is constructed from memory components inspired by existing memory frameworks\. This makes the search process interpretable, controllable, and comparable with prior human\-designed systems, but it also means thatAutoMemmainly discovers new combinations of known memory mechanisms\. Future work can move beyond recombination and explore open\-ended memory architecture generation, where the system can propose entirely new memory modules, interfaces, update rules, or cross\-module interaction patterns\. Coupling such architecture invention with executable validation and cost\-aware evaluation may further enable LLM agents to evolve from selecting among predefined memory designs toward creating genuinely novel and self\-improving memory systems\.

## References

- \[1\]Yuxuan Cai, Yipeng Hao, Jie Zhou, Hang Yan, Zhikai Lei, Rui Zhen, Zhenhua Han, Yutao Yang, Junsong Li, Qianjun Pan, et al\.Building self\-evolving agents via experience\-driven lifelong learning: A framework and benchmark\.arXiv preprint arXiv:2508\.19005, 2025\.
- \[2\]Joon Sung Park, Joseph C\. O’Brien, Carrie J\. Cai, Meredith Ringel Morris, Percy Liang, and Michael S\. Bernstein\.Generative agents: Interactive simulacra of human behavior, 2023\.
- \[3\]Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G\. Patil, Ion Stoica, and Joseph E\. Gonzalez\.Memgpt: Towards llms as operating systems, 2024\.
- \[4\]Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav\.Mem0: Building production\-ready ai agents with scalable long\-term memory, 2025\.
- \[5\]Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, and Yongfeng Zhang\.A\-mem: Agentic memory for llm agents, 2025\.
- \[6\]Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao\.Reflexion: Language agents with verbal reinforcement learning, 2023\.
- \[7\]Andrew Zhao, Daniel Huang, Quentin Xu, Matthieu Lin, Yong\-Jin Liu, and Gao Huang\.Expel: Llm agents are experiential learners, 2024\.
- \[8\]Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar\.Voyager: An open\-ended embodied agent with large language models, 2023\.
- \[9\]Zora Zhiruo Wang, Jiayuan Mao, Daniel Fried, and Graham Neubig\.Agent workflow memory, 2024\.
- \[10\]Boyuan Zheng, Michael Y\. Fatemi, Xiaolong Jin, Zora Zhiruo Wang, Apurva Gandhi, Yueqi Song, Yu Gu, Jayanth Srinivasa, Gaowen Liu, Graham Neubig, and Yu Su\.Skillweaver: Web agents can self\-improve by discovering and honing skills, 2025\.
- \[11\]Mirac Suzgun, Mert Yuksekgonul, Federico Bianchi, Dan Jurafsky, and James Zou\.Dynamic cheatsheet: Test\-time learning with adaptive memory, 2025\.
- \[12\]Xiangru Tang, Tianrui Qin, Tianhao Peng, Ziyang Zhou, Daniel Shao, Tingting Du, Xinming Wei, Peng Xia, Fang Wu, He Zhu, Ge Zhang, Jiaheng Liu, Xingyao Wang, Sirui Hong, Chenglin Wu, Hao Cheng, Chi Wang, and Wangchunshu Zhou\.Agent kb: Leveraging cross\-domain experience for agentic problem solving, 2025\.
- \[13\]Pengfei Du\.Memory for autonomous llm agents: Mechanisms, evaluation, and emerging frontiers, 2026\.
- \[14\]Guibin Zhang, Haotian Ren, Chong Zhan, Zhenhong Zhou, Junhao Wang, He Zhu, Wangchunshu Zhou, and Shuicheng Yan\.Memevolve: Meta\-evolution of agent memory systems, 2025\.
- \[15\]Jiaqi Liu, Xinyu Ye, Peng Xia, Zeyu Zheng, Cihang Xie, Mingyu Ding, and Huaxiu Yao\.Evolvemem: Self\-evolving memory architecture via autoresearch for llm agents, 2026\.
- \[16\]Shengran Hu, Cong Lu, and Jeff Clune\.Automated design of agentic systems, 2025\.
- \[17\]Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, Xionghui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, Bingnan Zheng, Bang Liu, Yuyu Luo, and Chenglin Wu\.Aflow: Automating agentic workflow generation, 2025\.
- \[18\]Mingchen Zhuge, Wenyi Wang, Louis Kirsch, Francesco Faccio, Dmitrii Khizbullin, and Jürgen Schmidhuber\.Language agents as optimizable graphs, 2024\.
- \[19\]Wangchunshu Zhou, Yixin Ou, Shengwei Ding, Long Li, Jialong Wu, Tiannan Wang, Jiamin Chen, Shuai Wang, Xiaohua Xu, Ningyu Zhang, Huajun Chen, and Yuchen Eleanor Jiang\.Symbolic learning enables self\-evolving agents, 2024\.
- \[20\]Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, and Jeff Clune\.Darwin godel machine: Open\-ended evolution of self\-improving agents, 2026\.
- \[21\]Reid Pryzant, Dan Iter, Jerry Li, Yin Tat Lee, Chenguang Zhu, and Michael Zeng\.Automatic prompt optimization with "gradient descent" and beam search, 2023\.
- \[22\]Mert Yuksekgonul, Federico Bianchi, Joseph Boen, Sheng Liu, Zhi Huang, Carlos Guestrin, and James Zou\.Textgrad: Automatic "differentiation" via text, 2024\.
- \[23\]Chengrun Yang, Xuezhi Wang, Yifeng Lu, Hanxiao Liu, Quoc V\. Le, Denny Zhou, and Xinyun Chen\.Large language models as optimizers, 2024\.
- \[24\]Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T\. Joshi, Hanna Moazam, Heather Miller, Matei Zaharia, and Christopher Potts\.Dspy: Compiling declarative language model calls into self\-improving pipelines, 2023\.
- \[25\]Shaokun Zhang, Ming Yin, Jieyu Zhang, Jiale Liu, Zhiguang Han, Jingyang Zhang, Beibin Li, Chi Wang, Huazheng Wang, Yiran Chen, and Qingyun Wu\.Which agent causes task failures and when? on automated failure attribution of llm multi\-agent systems, 2025\.
- \[26\]Guibin Zhang, Junhao Wang, Junjie Chen, Wangchunshu Zhou, Kun Wang, and Shuicheng Yan\.Agentracer: Who is inducing failure in the llm agentic systems?, 2025\.
- \[27\]Kunlun Zhu, Zijia Liu, Bingxuan Li, Muxin Tian, Yingxuan Yang, Jiaxun Zhang, Pengrui Han, Qipeng Xie, Fuyang Cui, Weijia Zhang, Xiaoteng Ma, Xiaodong Yu, Gowtham Ramesh, Jialian Wu, Zicheng Liu, Pan Lu, James Zou, and Jiaxuan You\.Where llm agents fail and how they can learn from failures, 2025\.
- \[28\]Preston Rasmussen, Pavlo Paliychuk, Travis Beauvais, Jack Ryan, and Daniel Chalef\.Zep: A temporal knowledge graph architecture for agent memory, 2025\.
- \[29\]Wanjun Zhong, Lianghong Guo, Qiqi Gao, He Ye, and Yanlin Wang\.Memorybank: Enhancing large language models with long\-term memory, 2023\.
- \[30\]Runnan Fang, Yuan Liang, Xiaobin Wang, Jialong Wu, Yuchen Eleanor Jiang, Wangchunshu Zhou, Huajun Chen, and Ningyu Zhang\.Memp: Exploring agent procedural memory, 2025\.
- \[31\]Grégoire Mialon, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, and Thomas Scialom\.Gaia: a benchmark for general ai assistants, 2023\.
- \[32\]Jialong Wu, Wenbiao Yin, Yong Jiang, Zhenglin Wang, Zekun Xi, Runnan Fang, Linhai Zhang, Yulan He, Deyu Zhou, Pengjun Xie, and Fei Huang\.Webwalker: Benchmarking llms in web traversal, 2025\.
- \[33\]Kaiyuan Chen, Yixin Ren, Yang Liu, Xiaobo Hu, Haotong Tian, Tianbao Xie, Fangfu Liu, Haoye Zhang, Hongzhang Liu, Yuan Gong, Chen Sun, Han Hou, Hui Yang, James Pan, Jianan Lou, Jiayi Mao, Jizheng Liu, Jinpeng Li, Kangyi Liu, Kenkun Liu, Rui Wang, Run Li, Tong Niu, Wenlong Zhang, Wenqi Yan, Xuanzheng Wang, Yuchen Zhang, Yi\-Hsin Hung, Yuan Jiang, Zexuan Liu, Zihan Yin, Zijian Ma, and Zhiwen Mo\.xbench: Tracking agents productivity scaling with profession\-aligned real\-world evaluations, 2025\.
- \[34\]Licheng Wen, Daocheng Fu, Xin Li, Xinyu Cai, Tao Ma, Pinlong Cai, Min Dou, Botian Shi, Liang He, and Yu Qiao\.Dilu: A knowledge\-driven approach to autonomous driving with large language models, 2024\.
- \[35\]Zhenhailong Wang, Haiyang Xu, Junyang Wang, Xi Zhang, Ming Yan, Ji Zhang, Fei Huang, and Heng Ji\.Mobile\-agent\-e: Self\-evolving mobile assistant for complex tasks, 2025\.
- \[36\]Tianrui Qin, Qianben Chen, Sinuo Wang, He Xing, King Zhu, He Zhu, Dingfeng Shi, Xinxin Liu, Ge Zhang, Jiaheng Liu, Yuchen Eleanor Jiang, Xitong Gao, and Wangchunshu Zhou\.Flash\-searcher: Fast and effective web agents via dag\-based parallel execution, 2025\.
- \[37\]Huichi Zhou, Yihang Chen, Siyuan Guo, Xue Yan, Kin Hei Lee, Zihan Wang, Ka Yiu Lee, Guchun Zhang, Kun Shao, Linyi Yang, and Jun Wang\.Memento: Fine\-tuning llm agents without fine\-tuning llms, 2025\.
- \[38\]Luyu Gao, Xueguang Ma, Jimmy Lin, and Jamie Callan\.Precise zero\-shot dense retrieval without relevance labels, 2022\.
- \[39\]Jaime Carbonell and Jade Goldstein\.The use of MMR, diversity\-based reranking for reordering documents and producing summaries\.InProceedings of the 21st Annual International ACM SIGIR Conference on Research and Development in Information Retrieval, pages 335–336, 1998\.

## Appendix AExperience Extraction Prompts

`Memory Extraction Prompt \(placeholder\) Example units produced by these prompts are shown in Appendix B\.5\.`

`Appendix B Worked Examples from the Search State This appendix shows what the optimization state of AutoMem looks like at runtime\. All artifacts are verbatim outputs from search runs on GAIA, WebWalkerQA, and xBench\-DeepSearch, lightly abridged for presentation: ellipses mark omitted fields, floating\-point digits are truncated, and non\-ASCII symbols are rendered in ASCII \(e\.g\. \-\>\)\. Accuracies appearing inside these artifacts are intermediate statistics on small search batches; they illustrate the mechanism and are not the results reported in §5\. B\.1 One Optimization Round, End to End We trace rounds 2–3 of a search run on xBench\-DeepSearch\. At round 2 the incumbent architecture extracts tip, trajectory, and insight units into all\-JSON storage with hybrid retrieval and lightweight management\. FGMD aggregates the round’s failures into the textual gradient below\. Note the scope gate at work: the budget\_capped failures are tagged out\-of\-scope and do not drive architecture edits\. Round\-2 textual gradient \(xBench\-DeepSearch run, abridged\) The gradient names one coordinate \(Retrieve\) and a direction\. In round 3 the proposer emits single\-coordinate edits of the incumbent along this gradient: one candidate applies the suggested edit \(retrieval hybrid \-\> contrastive\), and a second probes an alternative option on the same coordinate \(hybrid \-\> cbr\_rerank\), keeping every other module fixed so that the round yields a controlled comparison\. Round\-3 candidate proposal \(verbatim\) The rationale cites the gradient’s evidence \(the same failing tasks\), the pool statistics, and explicitly separates inherited from mutated coordinates\. In the paired round\-3 evaluation both edits improve on the incumbent \(accuracy 0\.433 \-\> 0\.467 for contrastive, 0\.433 \-\> 0\.500 for cbr\-rerank\); the cbr\-rerank candidate becomes the new front leader, and the ledger distills the round into a new principle and a follow\-up experiment: Ledger update after round 3 \(abridged\) B\.2 A Synthesized Textual Gradient The object below is the textual gradient δt\+1\\delta\_\{t\+1\} of §4\.3 exactly as synthesized at the end of a round \(here, round 1 of a WebWalkerQA run\)\. The fields realize the tuple \(qt⋆,ℰt,ρt,ℛt\)\(q\_\{t\}^\{\\star\},\\mathcal\{E\}\_\{t\},\\rho\_\{t\},\\mathcal\{R\}\_\{t\}\): primary\_signal states the dominant bottleneck qt⋆q\_\{t\}^\{\\star\}, evidence\_task\_ids grounds the evidence ℰt\\mathcal\{E\}\_\{t\}, confidence is ρt\\rho\_\{t\}, and recommended\_action carries ℛt\\mathcal\{R\}\_\{t\}\. The out\_of\_scope\_for\_memory flag implements scope filtering, and cross\_source\_agreement records whether the rule\-based histogram and the LLM diagnostician point in the same direction\. Synthesized textual gradient \(WebWalkerQA run, round 1\) B\.3 Experience\-Ledger Entries Each ledger entry realizes the tuple ℓ=\(c,u,q,z\)\\ell=\(c,u,q,z\) of §4\.2: the claim states the condition and the edit, evidence is the supporting record qq, and status is the lifecycle state zz\. The first principle below accumulated consistent evidence over seven rounds of a GAIA run \(20 evidence entries; confidence 0\.86\) and encodes a measurement insight—a higher retrieval hit\-rate does not imply higher accuracy\. The second shows differential validation at work: a paired comparison supported the claim in round 6, the same paired comparison contradicted it in round 7, and the principle was downgraded to refuted, so the proposer stops following that edit\. An active and a refuted principle \(GAIA run, abridged\) Dead\-end entries record an architecture region that should not be re\-proposed while the entry stays active\. The recorded reason matters: in the entry below, the hit\-rate was high and 91% of the failures were out of memory’s scope, so further retrieval edits in that region would chase noise\. A dead\-end entry \(GAIA run, verbatim\) B\.4 An Observation\-Graph Excerpt The excerpt below shows the observation graph 𝒢\\mathcal\{G\} of a WebWalkerQA run after six rounds: two task\-pattern nodes and three of its 32 edges\. The edge attributes n\_trials and avg\_acc are exactly the n​\(c,u\)n\(c,u\) and the running average behind μ​\(c,u\)\\mu\(c,u\) in §4\.2\. The graph is serialized into the proposer prompt as a soft prior over module choices\. Observation\-graph excerpt \(WebWalkerQA run, abridged\) B\.5 Example Memory Units We close with one memory unit per type, extracted by the prompts of Appendix A from GAIA trajectories\. Tip and insight units are declarative; trajectory, workflow, and shortcut units are procedural at increasing levels of abstraction—a grounded trace, a generalized template with <PLACEHOLDER\> slots, and an executable macro with an input schema\. Note that the insight unit is extracted from a failed task, and that every unit carries use\_when/avoid\_when guards that are checked at injection time\. Tip unit \(declarative heuristic\) Insight unit \(root\-cause analysis of a failed task\) Trajectory unit \(grounded action–observation trace\) Workflow unit \(generalized multi\-step template\) Shortcut unit \(executable macro with input schema\) Appendix C Implementation Details Memory schema, storage backends, retrieval strategies, management ops; the exact factored search space over \(E,S,R,M\)\(E,S,R,M\) and its cross\-module constraints; observation\-graph update rule; ledger schema\. Table 5 lists the full per\-module component menu together with the prior work each option draws on\. Table 5: The per\-module component menu of the factored search space \(§3\.1\) and its lineage\. Each option is selectable and routable by the proposer; cross\-module constraints \(e\.g\., graph retrieval requires a graph\-family store\) keep every \(E,S,R,M\)\(E,S,R,M\) path valid by construction\. Module Option Lineage Encode tip \(transferable heuristics\) \[7, 6\] insight \(failure root\-cause\) \[6, 7\] trajectory \(action–observation\) \[2, 3\] workflow \(orchestration logic\) \[9, 30\] shortcut \(parameterized macro\) \[8, 10\] Store json \(exact key–value\) — vector \(FAISS dense index\) \[4, 3\] hybrid \(json \+\+ vector\) — graph \(entity–relation, NetworkX\) \[5\] llm\_graph \(LLM temporal KG\) \[28\] Retrieve hybrid \(lexical \+\+ semantic\) — contrastive \(success/failure cohort\) \[7\] cbr\_rerank \(case\-bank \+\+ rerank\) \[37\] graph \(multi\-hop traversal\) \[5\] hyde \(hypothetical\-document embed\) \[38\] mmr \(diversity reranking\) \[39\] Manage lightweight \(forget\) \[29\] json\_full \(merge \+\+ update\) \[4, 9\] tool\_manager \(validate\) \[8, 11\] graph\_consolidate \(merge \+\+ evolve\) \[5, 37\] Appendix D Algorithm Details Pseudocode for the optimization loop and the diagnostic pipeline\. Appendix E Supplementary Experiments and Reproducibility Table 6: Search budget and reproducibility details \(cf\. §5\.3\), ensuring AutoMem, random search, and the fixed baselines are compared under transparent, comparable budgets\. All splits are disjoint and stratified with a fixed seed \(42\)\. On WebWalkerQA and xBench\-DS the memory pool is seeded by the first search round instead of a separate warm\-up split; on WebWalkerQA the validation and held\-out tasks come from websites unseen during search\.`