Dream-RSI

Dream-RSI (Recursive Self-Improvement through Evolving Worlds) is a framework for improving the exploration strategy of an AI discovery agent, described in a preprint posted to arXiv on 14 September 2026 by a 17-author team from Google, Google DeepMind, the University of Maryland, College Park, and the University of Virginia ^[1]. Its central idea is that a completed discovery run, once organized as a tree of exploration decisions and their recorded code-execution outcomes, is already a simulator: an alternative exploration policy can be scored by walking that tree in a different order, without rerunning the coding agent or the evaluator. Dream-RSI uses this "replay simulator" to test candidate exploration policies offline, a step the authors call dreaming by analogy with model-based reinforcement learning and the Dreamer family of agents, and then redeploys the best policy for the next round of live discovery ^[1][2].

The paper reports results on eight discovery tasks in three domains (a Lasso regularization-path solver, three mathematical optimization problems, and four GPU kernel tasks from KernelBench). Against a controlled baseline that keeps its exploration policy fixed, Dream-RSI reached better downstream solver quality with 1.7 times fewer discovery-agent calls on the Lasso task, and on the kernel tasks it either matched performance with 1.79 to 2.43 times fewer generations or improved performance by up to 2.09 times at a comparable budget ^[1][2]. The scope of the claim is narrow: only the exploration-policy code changes between rounds. The underlying models, the evaluator, and the execution interfaces stay fixed, and the project README states "zero gradient steps on the coding agent" ^[2][3]. Commentary on X on 16 September 2026 framed the paper as Google demonstrating or "cracking" recursive self-improvement; the paper's own wording describes a self-improvement loop at the meta-exploration layer and says the gains hold "in several settings" ^[1][12][13].

The problem: exploration is the bottleneck

The paper starts from the observation that recursive self-improvement, as practiced in 2026, runs on an iterative discovery loop in which an agent proposes candidate solutions, evaluates them, incorporates feedback, and refines the next iteration. The authors cite this pattern in algorithm design (AlphaEvolve, FunSearch), open-ended mathematical optimization, systems design, and agent self-improvement, and note that as targets get harder, discovery stretches over thousands of proposal-evaluation cycles ^[1]. What decides whether those cycles are worth their compute is exploration: where to branch, what to run in parallel, and when to stop a line of attempts ^[1][4].

Most existing systems hard-code that exploration strategy and leave it fixed for the whole run. The paper names AlphaEvolve, PACEvolve, DeltaEvolve, MLEvolve, and SimpleTES as examples of manually designed strategies that remain largely fixed throughout discovery ^[1]. A fixed strategy cannot learn from the experience it accumulates and may keep paying for directions that have already failed. The obvious alternative, optimizing the exploration policy online during discovery (the paper points to EvoX as recent work in this direction ^[11]), runs into two problems the authors describe as fundamental. Feedback at the meta level is delayed and expensive, because judging an exploration policy means watching it steer an entire discovery process rather than scoring one candidate. And the meta-policy space is vast, so many proposed policies will be poor and each one costs a full online rollout to find out ^[1].

The key idea: history is already a simulator

The paper's answer is that the expensive feedback has already been paid for. A finished discovery run records a structured tree: every exploration decision the agent made, each carrying the execution outcome it actually produced (filesystem snapshot, generated artifact, evaluator diagnostics, and score). An exploration policy does one thing, which is to decide, given what it has seen so far, which attempts to continue next. So an alternative policy can be evaluated by traversing the same recorded tree differently: a different subset of branches, in a different order, with different parallel groupings and different stopping points. Because every outcome along the way is already stored, the evaluation requires only reading past records. The paper uses the terms "replay simulator" and "worlds" interchangeably for this object ^[1].

The authors draw the analogy to model-based reinforcement learning and world models, citing Ha and Schmidhuber's 2018 World Models paper and the Dreamer line of agents (Hafner et al., 2019 to 2025), which learn a compact dynamics model from experience and improve a policy by imagining trajectories inside it ^[1][8][9]. The project site draws the contrast sharply: the replay simulator is "not a learned world model and not an approximation," because it is the realized search space itself, and nothing in it is predicted. The same page states the limit just as plainly: a policy can only be dreamt where history actually went ^[4]. That limit is what makes Dream-RSI a loop rather than a one-off. Each online deployment records another tree, so the agent owns a growing pool of worlds; a policy scored across more worlds is, in the authors' framing, less tuned to the luck of a single run, and it comes back with worlds that no earlier policy could have reached ^[4].

The paper also positions this against two prior ways of using discovery history: as static textual context for prompting (it cites work on agent memory and ReasoningBank) and as training data for weight fine-tuning (ThetaEvolve and TTS-Discovery). Dream-RSI instead treats the history as an interactive environment ^[1].

How the loop works

Dream-RSI alternates between online exploration and offline dreaming. The system has four fixed parts and one moving part. The fixed parts are the discovery agent (a coding agent that produces candidate solutions), the evaluator (which scores candidates and returns diagnostic feedback), the execution interfaces, and an LLM-based "policy-development agent" that rewrites policy code. The moving part is the exploration policy, which is executable code that allocates discovery computation ^[1].

Source: paper Figure 1 and Section 3 ^[1].

Discovery trees and the decision interface

A discovery tree is rooted at a node representing the initial workspace state. Every other node has exactly one parent, either the root or an earlier node, and that parent is where the attempt begins: the discovery agent resumes the parent's saved workspace, uses its accumulated observations as context, and produces a new attempt. The node records the outcome of that generation-evaluation attempt, including a filesystem snapshot, the generated artifact, evaluator diagnostics, and a score under a fixed task-scoring protocol where larger is better ^[1].

In both online execution and offline replay, the policy observes the tree it has revealed so far and picks a batch of nodes from which to continue. The eligible nodes are the root plus the current leaves. With W parallel workers (for example, concurrent API calls), a batch can contain up to W nodes, so each decision determines both where exploration continues and how many attempts run in parallel. Online and offline phases share this decision interface and differ only in what happens after a batch is selected ^[1].

Online rollout

At outer iteration t, the policy guides a fresh rollout with read access to the completed history but builds a new tree. The policy code is frozen for the whole rollout. Each round, it chooses a batch, each selected node is assigned to a worker, the coding agent produces a new candidate from that node's workspace, and the evaluator scores it, adding one child per selected node. The transition is stochastic, because the coding agent may produce different outcomes from the same starting workspace. The rollout ends when the policy selects an empty batch or hits the round limit; the finished tree is then appended to the history ^[1].

Offline replay and the replay objective

During the offline phase the history is fixed. The method builds M policy versions, starting with the currently deployed policy as version zero, and evaluates each version separately on every historical tree before the next version is written. In replay, selecting a node reveals its recorded child deterministically rather than generating a new candidate. For a non-root node that is its unique recorded child; for the root, replay returns the earliest-created child not yet revealed, opening one previously unseen branch. Replay stops when the policy selects an empty batch, reaches a round limit, or has revealed the entire recorded tree. Each branch is traversed in its recorded parent-child order and no outcome beyond the recorded tree is ever generated ^[1].

The replay score for one policy on one tree has three terms: the best score attained during replay (discovery quality), minus a penalty proportional to the number of revealed non-root nodes (execution cost, since each revealed node stands for one generation-evaluation request), plus a bonus proportional to the average number of attempts per decision round (a parallelism bonus that favors policies that batch useful continuations rather than execute them one at a time). Two fixed coefficients weight the penalty and the bonus ^[1].

Policy improvement and the "no worse" property

A policy version's evaluation score is its average replay score across all trees in the history. After scoring version zero, the policy-development agent examines the replay trajectories and scores, together with feedback from earlier revisions, to identify successful decisions and recurring failures, and then revises the executable policy code. After M revisions, the next online policy is the version with the highest average replay score. Because the current policy is itself in the candidate set, the selected policy is never worse than the current one in average replay score on the fixed history. The paper states this property precisely in those terms; it is a guarantee about replay score on recorded trees, not about the next online rollout, whose transitions are stochastic ^[1].

What a policy actually is

The policy is a Python class. The replay-improvement prompt reproduced in the paper's Appendix B instructs the policy-development agent to edit a single method file and implement OptimalPolicy.solve(self, question, budget=None), a subclass of LLMDesignedMethod, and forbids it from solving the scientific task itself or editing any other program. The environment it sees is described as "a frozen, irregular branch x attempt grid" in which a policy either opens a new root or refines the next cell of an already-open branch, and each revealed cell costs one probe ^[1].

Several constraints in that prompt shape what kind of policy can be learned. The policy is "prefix-only": it may use revealed observations, the baseline score, the legal action sets, structural metadata, and helper signals, but never unrevealed scores, a true optimum, hard-coded winning cell identifiers, or absolute score targets. It must reconstruct each opened branch's full trajectory rather than looking only at the latest observation, and it must classify a failed frontier as hard-unrecoverable, a repairable implementation failure, weak-but-underexplored, or repeatedly unpromising before closing it; the prompt states that output mismatches, resource limits, and shape or layout errors are normally repairable and that algorithmic failure should not be inferred from one such error. Each decision round must build one "dynamic portfolio" batch of independent candidates mixing exploitation, exploration, and at most one recovery attempt, must never sample randomly, and must never place a parent and its child in the same batch ^[1].

The policy exposes a single scalar knob, beta, which is fixed within one live or replay episode: high beta means more width, deeper patience, and weaker pruning; low beta means fewer probes and earlier stagnation stops. Offline evaluation sweeps a fixed grid of beta values and ranks the resulting curve by an area-under-curve reward minus a parallelism penalty, and the development agent chooses the next default beta from the last two or three live cycles (raising it by about 0.1 to 0.2 when a plateau appears and the sweep shows higher attainment at higher beta, or falling back to about 0.6 when evidence is insufficient). Every policy must also implement a deterministic plan_grid method that chooses the branch count and refinement count for the next live grid before it is created, using only completed earlier manifests ^[1].

The online exploration prompt, also reproduced in the appendix, tells the coding agent to read every historical proposal and its score before proposing anything, to distinguish flawed ideas from good ideas undone by bugs, to resist further small tweaks when attempts cluster around one mechanism with flattening returns, and never to claim a solution compiles or beats the state of the art until it has been evaluated ^[1].

What does not change

The paper is explicit that "only the exploration-policy code changes; the underlying models, evaluator, and execution interfaces remain fixed" ^[1]. The README's summary graphic states "Zero gradient steps on the coding agent" ^[3]. Dream-RSI therefore belongs to the family of self-evolving systems that modify a controller or orchestration layer rather than model weights. The paper's own related-work section draws the line differently: it lists prior self-evolving agents that change weights, harnesses, contexts, skills, test-time behavior, rubrics, or environments, notes that most of them operate at the object level, and positions Dream-RSI as optimizing a meta-level mechanism (the search strategy) recursively and off-policy ^[1].

Experimental setup

All experiments compare Dream-RSI with a controlled baseline the paper calls Recursive Fixed Exploration: the same discovery agent, evaluator, initialization, and per-round resource constraints, but with the exploration policy held fixed across rounds. Both methods start from the same hand-written policy, a simple "parallel refining" strategy that launches several independent workspaces in parallel, each repeatedly refining its own current candidate using the history accumulated within that workspace. The two methods are therefore identical in round one by construction and diverge afterward. Discovery cost is measured as the cumulative number of discovery-agent calls ^[1].

The discovery agents are Gemini 3.1 Pro and Gemini 3.7 Flash, driven through the Gemini CLI ^[1][14].

Dream-RSI keeps identical per-round budgets ^[1].

Algorithm engineering: the Lasso regularization path

The algorithm-engineering task is to discover a fast, numerically correct implementation of the complete Lasso regularization path, following the benchmark setting of SimpleTES (Ye et al., 2026), a discovery system from a separate group that used the open-weight GPT-OSS 120B model with a reported budget of 51,200 generations ^[1][5]. Discovery uses the same 17 synthetic instances as SimpleTES; the discovered solvers are then timed on six held-out datasets (Gisette, RCV1, DNA, Leukemia, Colon, and Duke Breast). A candidate passes only if, on fresh correctness instances, its objective value at every point on the path is no more than 10^-6 above scikit-learn's; otherwise its search score is zero. Both Dream-RSI and the fixed baseline ran for five rounds ^[1].

Final wall-clock runtime in milliseconds on the six held-out datasets; lower is better. Source: paper Figure 3(a) ^[1].

With Gemini-3.1 Pro, Dream-RSI cut the average held-out runtime from 3587.1 ms to 2931.0 ms while using 317 discovery-agent calls against 550 for the fixed policy, which is the source of the README's "1.22x faster downstream runtime, 1.74x less discovery compute" summary and the paper's "1.7x" figure ^[1][3]. With Gemini-3.7-Flash it went from 2516.7 ms to 2350.6 ms using 1879 calls instead of 3200. Against SimpleTES's 51,200 generations, 317 calls is roughly 162 times fewer, the number that circulated most widely ^[1][3]. The discovered solvers also beat sklearn and glmnet on all six held-out datasets ^[1].

The per-dataset numbers deserve a closer look than the averages. The Gemini-3.1 Pro Dream-RSI solver is faster than its fixed-exploration counterpart only on RCV1, the largest matrix, and is slower on the other five datasets; because RCV1's runtime dominates the arithmetic mean, the average still favors Dream-RSI. The paper acknowledges this directly, noting that the program discovered by Gemini-3.1-Pro "appears particularly well suited to large-scale matrices such as RCV1," whereas the Gemini-3.7-Flash program is more general-purpose and performs consistently across problem scales ^[1]. It is also worth noting that the authors' own reproduction of SimpleTES (8318.4 ms average) is more than twice as slow as the figure SimpleTES reported (3804.8 ms); the paper marks the row only with a dagger, which the project site glosses as "our reproduction", and neither discusses the gap ^[1][4].

The Lasso solver discovered by Dream-RSI, reproduced in full in Appendix C, is C++ built on the Eigen library. Rather than switching between LARS and coordinate descent by problem dimension as SimpleTES's solver does, it introduces adaptivity inside the active-set optimization: strong-rule screening combined with Cauchy-Schwarz-based KKT pruning, recomputing exact gradients only when the bound cannot certify a feature, and falling back to a full refresh when pruning becomes ineffective, together with lazy Gram-matrix construction and hardware-aware implementation ^[1].

Mathematical optimization

The three mathematical tasks are the sum-difference problem (find a finite set of integers whose normalized sumset is large relative to its normalized difference set), circle packing in a unit square (maximize the sum of radii for n in {26, 32}), and the autocorrelation inequalities (find functions on [-1/4, 1/4] that minimize or maximize autoconvolution-based objectives). All three are problems previously attacked by AlphaEvolve and its successors ^[1][6][7]. Gemini-3.1 Pro via the Gemini CLI served as the discovery agent for both Dream-RSI and the fixed baseline, run for ten rounds ^[1].

Source: paper Table 1; blank cells are values the paper does not report ^[1].

Dream-RSI's sum-difference score of 1.145427 is the best in the table, ahead of SimpleTES (1.143975) and the fixed baseline (1.144047). On circle packing it reaches 2.635983, tying the best reported value, which five other systems also reach. On the autocorrelation inequality the best entry is SimpleTES at 1.453675; Dream-RSI's 1.456375 is slightly behind both SimpleTES and its own fixed-exploration baseline (1.456001), which the paper describes as "remaining competitive" while pointing out that SimpleTES used 51,200 generations against fewer than 1,000 here, a budget difference the introduction summarizes as "over 50x" ^[1]. The appendix defines the circle-packing task for n = 26 and n = 32; the table reports a single value.

GPU kernel engineering

The kernel tasks come from KernelBench (Ouyang et al., 2025), a benchmark of PyTorch workloads that a model must reimplement as faster GPU kernels while matching a reference implementation ^[10]. The paper uses four tasks: VGG16, LayerNorm, ConvDiv, and ConvMax. Candidates are scored by inverse runtime (1/ms) subject to correctness checks. Gemini-3.1 Pro is the coding agent for both methods, under the same evaluation protocol and initialization, and results are presented as discovery trajectories against the number of generations, up to about 1,000 ^[1].

Source: paper Figure 4 and Section 4.3 ^[1].

The README's summary of "4 of 4 kernels improved" refers to these four results ^[3].

Further analysis

Two analyses in Section 5 bear on why replay works. The first compares replay with what the authors call a natural alternative: abstracting past trajectories into high-level directional insights and injecting them into the prompt as explicit semantic guidance. Applied to both the fixed baseline and Dream-RSI on ConvDiv, this guidance consistently underperformed the unguided version under equal budgets. The authors' interpretation is that in long-horizon discovery with many parallel threads, strong semantic priors about where to search over-constrain the space and suppress diverse exploration ^[1].

The second analysis tracks how the learned policy's behavior changes across rounds on ConvDiv. The pattern is adaptive rather than monotonically greedier or broader: as performance improves, the policy first conserves compute, cutting the number of evaluated attempts per round from 110 to 50; when progress plateaus, it spends more again, and those widenings coincide with the next gains in round-best performance ^[1][4].

Relation to other discovery systems

Dream-RSI sits in a crowded 2025-2026 lineage of LLM-driven discovery loops. The paper's related-work section lists AlphaEvolve, OpenEvolve, CodeEvolve, ShinkaEvolve, PACEvolve, DeltaEvolve, and MLEvolve as systems that generate, evaluate, and refine candidates using prior artifacts and feedback; SkyDiscover, SwarmResearch, and EvoX as more recent work that emphasizes exploration itself; and a separate strand of self-evolving agents that modify weights, harnesses (Meta-Harness, the Darwin Godel Machine), contexts, skills, rubrics, or environments ^[1]. Two distinctions the authors draw are that Dream-RSI operates at the meta level (improving the controller that decides how to search, not the candidates) and that it does so off-policy, evaluating controllers against recorded history rather than through new rollouts ^[1].

Several of the paper's authors have prior work in this space. Tong Zheng is first author of the cited "LLMs Improving LLMs: Agentic Discovery for Test-Time Scaling" (arXiv 2605.08083), with Haolin Liu, Rui Liu, and Xidong Wu among its co-authors; Benjamin Coleman, Zhankui He, and Wang-Cheng Kang are authors of both PACEvolve and PACEvolve++; and Xidong Wu, Yue Zhuan, Ruoqiao Wei, Di Bai, Xue Wang, and Xinwu Cheng are co-authors of AgenticRecTune, a self-evolving multi-agent system for recommendation optimization ^{[1][15][16][17]}.

Scope and caveats

The preprint does not contain a dedicated limitations section. The following boundaries come from the paper's and the project site's own statements.

• The replay simulator is exact only over the search space that was actually visited. Replay can reveal recorded children in a different order but cannot generate outcomes the original run never produced; the project site calls this the method's sharp limit and the reason the approach must run as a loop ^[1][4].
• The "never worse" property holds for average replay score on the fixed recorded history. The paper does not claim that a policy which scores better in replay must perform better in its next online rollout, and it notes that online transitions are stochastic ^[1].
• The self-improvement is confined to exploration-policy code. Model weights, the evaluator, and the execution interfaces are fixed, and the paper's headline conclusion is that Dream-RSI "achieves competitive or improved discovery quality while substantially reducing discovery cost in several settings," not in all of them ^[1].
• On autocorrelation, Dream-RSI's score is behind both SimpleTES and its own fixed-exploration baseline; on the Lasso task with Gemini-3.1 Pro, its per-dataset advantage over the fixed policy comes from one large dataset ^[1].
• The primary comparison is against a single controlled baseline built by the same authors, with a single hand-written starting policy. The comparison with published systems in Table 1 mixes different models and generation budgets ^[1].
• As of 16 September 2026 the repository contains the paper PDF, figures, and citation metadata but no code, so the results cannot yet be reproduced from the released materials ^[2].

Reception

The paper circulated widely on X on 16 September 2026, two days after posting. Mark Kretschmann wrote that "Google may have just cracked recursive self-improvement!" while also noting that the method "does not rewrite the model's weights" and improves "the policy deciding where to branch, what to run in parallel and when to stop," calling it "recursive self-improvement at the meta layer" ^[13]. The account Dr Singularity posted that "Google just demonstrated a recursive self improvement loop for AI discovery," repeating the 162x figure and adding that the system "improves the exploration policy, not the underlying model weights" ^[12]. Both posts described the authors as Google or Google DeepMind researchers; the paper's affiliation list is Google, University of Maryland, College Park, Google DeepMind, and University of Virginia, and the corresponding authors are at Google ^[1]. The paper itself never uses the word "cracked" and describes its contribution as closing a self-improvement loop "at the meta-exploration layer" ^[1].

Authors and availability

The 17 authors are Tong Zheng (Google and University of Maryland), Xidong Wu (Google), Zheng Zhang (Google), Zhankui He (Google DeepMind), Chaoyi Zhang (Google), Benjamin Coleman (Google DeepMind), Ruoqiao Wei (Google), Di Bai (Google DeepMind), Haolin Liu (University of Virginia), Rui Liu (University of Maryland), Xue Wang (Google), Yue Zhuan (Google), Wang-Cheng Kang (Google DeepMind), Renkai Xiang (Google), Heng Huang (University of Maryland), Xinwu Cheng (Google), and Yunsong Guo (Google). Xidong Wu and Zheng Zhang are the corresponding authors. The paper carries a "2026 Google. All rights reserved" notice ^[1][2].

The README's badge row still reads "arXiv coming soon" and its release-plan table lists the arXiv posting as "in progress," even though the arXiv entry went live on 14 September; the repository's most recent commit, on 16 September, updated the README's BibTeX to the real identifier ^[2][3]. The Lasso solver discovered by Dream-RSI is printed in full in the paper's Appendix C, and the two prompts used for online exploration and replay-based policy improvement are in Appendix B ^[1].

References

1. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18 ^19 ^20 ^21 ^22 ^23 ^24 ^25 ^26 ^27 ^28 ^29 ^30 ^31 ^32 ^33 ^34 ^35 ^36 ^37 ^38 ^39 ^40 ^41 ^42 ^43 ^44 ^45 ^46 ^47 ^48 ^49 ^50 ^51 ^52 ^53 ^54 ^55 ^56 ^57 ^58Zheng, T., Wu, X., Zhang, Z., et al. "Dream-RSI: Recursive Self-Improvement through Evolving Worlds." arXiv:2609.14858, submitted 14 September 2026. arxiv.org/...2609.14858 (PDF: arxiv.org/...2609.14858)
2. ^1 ^2 ^3 ^4 ^5 ^6 ^7zhengkid/Dream-RSI, GitHub repository (created 13 September 2026). github.com/...Dream-RSI
3. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9Dream-RSI README, "Release plan" and summary statistics graphic. github.com/...README.md
4. ^1 ^2 ^3 ^4 ^5 ^6 ^7Dream-RSI project page. dream-rsi.com
5. ^Ye, H., et al. "Structured Scaling of AI Discovery Across Diverse Scientific Domains" (the SimpleTES paper; version 1 was titled "Evaluation-driven Scaling for Scientific Discovery," which is how Dream-RSI cites it). arXiv:2604.19341. arxiv.org/...2604.19341
6. ^Novikov, A., et al. "AlphaEvolve: A coding agent for scientific and algorithmic discovery." arXiv:2506.13131. arxiv.org/...2506.13131
7. ^Georgiev, B., Gomez-Serrano, J., Tao, T., Wagner, A. Z. "Mathematical exploration and discovery at scale." arXiv:2511.02864. arxiv.org/...2511.02864
8. ^Ha, D., Schmidhuber, J. "World Models." arXiv:1803.10122. arxiv.org/...1803.10122
9. ^Hafner, D., Pasukonis, J., Ba, J., Lillicrap, T. "Mastering Diverse Domains through World Models." arXiv:2301.04104. arxiv.org/...2301.04104
10. ^Ouyang, A., et al. "KernelBench: Can LLMs Write Efficient GPU Kernels?" arXiv:2502.10517. arxiv.org/...2502.10517
11. ^Liu, S., et al. "EvoX: Meta-Evolution for Automated Discovery." arXiv:2602.23413. arxiv.org/...2602.23413
12. ^1 ^2Dr Singularity (@Dr_Singularity), post on X, 16 September 2026. x.com/...2100204780010222076
13. ^1 ^2Mark Kretschmann (@mark_k), post on X, 16 September 2026. x.com/...2100185621356507425
14. ^Gemini CLI. geminicli.com
15. ^Zheng, T., Liu, H., Huang, C., et al. "LLMs Improving LLMs: Agentic Discovery for Test-Time Scaling." arXiv:2605.08083. arxiv.org/...2605.08083
16. ^Yan, M., Peng, B., Coleman, B., et al. "PACEvolve: Enabling Progress-Aware Consistent Evolution." arXiv:2601.10657. arxiv.org/...2601.10657 ; "PACEvolve++: Improving Test-time Learning for Evolutionary Search Agents." arXiv:2605.07039. arxiv.org/...2605.07039
17. ^Wu, X., Zhuan, Y., Wei, R., et al. "AgenticRecTune: Multi-Agent with Self-Evolving Skillhub for Recommendation System Optimization." arXiv:2604.26969. arxiv.org/...2604.26969