Evo-Rec: Framework for Evolving Algorithms

• Evo-Rec is an evolutionary framework that optimizes recommendation models and algorithms through iterative, memory-based, and executable optimization.
• The framework includes an evolving recommendation model, an evolving Skill library, and persistent structured memory to track experimental results.
• EvoRec's dual-track loop of model and skill self-evolution differentiates its optimization processes from conventional AutoML, which searches a predefined space, by systematically accumulating and applying generalized optimization knowledge.

Evo-Rec is an evolutionary framework for automated optimization in which recommendation models, executable algorithms, and the methodology used to improve them can evolve through repeated hypothesis generation, implementation, evaluation, memory accumulation, and methodological distillation. The name is principally associated with “EvoRec: Self Evolving Agentic Recommender Systems,” a multi-agent recommender-optimization framework that co-evolves a recommendation model and an optimization methodology (Mu et al., 15 Jun 2026). Related work extends the same design principle to white-box seismic reconstruction algorithms and to recoverability-constrained self-modification of LLM agent harnesses, providing architectural analogues and safety requirements for broader Evo-Rec systems (Xu et al., 18 Aug 2026, Sah et al., 28 Aug 2026).

1. Concept and scope

Evo-Rec treats optimization as an evolutionary process over executable artifacts rather than as isolated parameter tuning. In recommender systems, the evolving artifact is a model implemented through code; in algorithm-discovery settings, it may be a standalone reconstruction operator; and in mutable agent systems, it may include prompts, tools, middleware, resources, and execution policies.

The central distinction is between three forms of state:

• Model or algorithm: the executable artifact whose performance is being optimized.
• Memory: detailed records of hypotheses, code changes, outcomes, and failure attribution.
• Skills or methodology: reusable, declarative procedures distilled from multiple experiments.

This separation enables the system to preserve both local experimental evidence and generalized optimization knowledge. A model update changes the executable artifact, whereas a Skill changes how subsequent hypotheses are generated, implemented, or diagnosed.

In recommender optimization, the global state at round $t$ is represented as

$$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$

where $\theta_{t-1}$ is the current model state, $\mathcal{S}_t$ is the Skill library, and $\mathcal{M}_t$ is accumulated Memory (Mu et al., 15 Jun 2026). The framework therefore differs from conventional AutoML, which generally searches a predefined configuration space, and from code-generating agents that primarily translate a human-selected direction into implementation.

A broader algorithm-evolution interpretation is provided by SeisEvo. It searches for an algorithm $A$, rather than directly optimizing a reconstruction $\widehat X$:

$$A^\star=\operatorname{SeisEvo}(A_0,\mathcal{S},O,\mathcal{C};T),$$

where $A_0$ is a classical seed, $\mathcal{S}$ is the editable operator surface, $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$0 is the executable objective, $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$1 is the legality and provenance constraint set, and $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$2 is the search budget (Xu et al., 18 Aug 2026). This supports the interpretation of Evo-Rec as a general pattern for evolving interpretable computational procedures, although SeisEvo does not itself define a separately named Evo-Rec implementation.

2. EvoRec architecture and dual-track evolution

EvoRec contains an evolvable recommendation model, an evolvable Skill library, and persistent structured Memory. An Orchestrator Agent coordinates three specialist agents: the Research Agent, the Code Agent, and the Skill Evolver. Together these constitute four collaborating agents.

The Orchestrator activates the Research Agent and Code Agent in every model-optimization round. It collects the hypothesis, implementation, training outcome, and metrics; writes the complete trajectory to Memory; triggers Skill Evolution every $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$3 rounds; and terminates after $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$4 iterations, $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$5 consecutive non-improving rounds, or achievement of a target metric threshold.

The Research Agent combines external knowledge, Research Skills, and historical experiments:

$$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$6

Each hypothesis is represented as

$$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$7

Before proposing a direction, the agent applies a diversity constraint to avoid repeatedly modifying the same module and becoming trapped in a local optimum. Memory retrieval helps avoid unsuccessful directions, while Skills bias generation toward strategies that previously worked.

The Code Agent locates relevant model code, applies minimal-diff modifications, launches training, and returns logs and evaluation results. If a proposed change is infeasible, the Research Agent generates an alternative. The Code Agent does not merely produce source code: it participates in an executable hypothesis–implementation–validation cycle.

EvoRec uses a dual-track loop:

1. Model self-evolution occurs every round.
2. Skill self-evolution occurs periodically after a batch of model-evolution rounds.

At each round, the system retrieves context, checks diversity, generates a hypothesis, inspects and modifies code, performs a feasibility check, trains and evaluates the candidate, assigns a success, failure, or neutral verdict, persists the trajectory, and updates the model if the experiment is accepted as an improvement. Failed experiments remain in Memory rather than replacing the best model.

The dual-track design addresses two limitations of static optimization workflows: they do not systematically accumulate methodology, and they generally cannot introduce structural changes outside a predefined configuration space.

3. Memory, Skills, and open-domain exploration

Each EvoRec experiment is stored as

$$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$8

where $$\langle \theta_{t-1}, \mathcal{S}_t, \mathcal{M}_t\rangle,$$9 is the hypothesis, $\theta_{t-1}$0 is the code modification, $\theta_{t-1}$1 summarizes training logs, $\theta_{t-1}$2 is the offline metric vector, and

$\theta_{t-1}$3

The full history is

$\theta_{t-1}$4

Memory creates an inverted index over fields including the modified target module, verdict, metric delta relative to the prior model, and timestamp. It therefore records not only the final model but also the relationship between an intervention, its implementation, its measured effect, and its attribution.

Skills are declarative natural-language methodologies rather than model-specific code. A Skill is represented as

$\theta_{t-1}$5

Research Skills guide hypothesis formulation, Engineering Skills guide implementation, and Diagnosis Skills guide failure analysis and repair. The example “Hard Negative Mining” has a scope corresponding to a recall plateau, operational guidance prescribing popularity-weighted hard negatives with a temperature range, and evidence linked to successful Memory records.

Every $\theta_{t-1}$6 rounds, the Skill Evolver selects a recent batch of Memory records and balances them by verdict label according to a preset ratio $\theta_{t-1}$7. It generates candidate Skill patches, compares each candidate with existing Skills, merges similar candidates, refines sufficiently similar Skills, and creates new Skills when similarity is below the threshold $\theta_{t-1}$8. This produces the feedback loop

$\theta_{t-1}$9

The framework’s claimed expansion beyond a predefined search space arises from external knowledge retrieval and Skill creation. The reported case study includes learning-rate reduction, focal loss, increasing negative samples from 4 to 16, four-head multi-interest pooling, replacing BCE with InfoNCE, hard-negative mining, layer-wise learning-rate decay, and attention-head pruning (Mu et al., 15 Jun 2026).

This capability should be distinguished from a theoretical guarantee of unrestricted or globally complete search. EvoRec demonstrates structurally varied modifications, but it does not establish that all novel proposals are safe, useful, executable, or globally optimal.

4. Algorithm evolution beyond recommender systems

SeisEvo provides a concrete instance of evolutionary algorithm discovery. It begins with a classical reconstruction algorithm, exposes selected components for editing, generates executable candidates through parallel coding agents, rejects candidates that violate physical or interface constraints, scores legal candidates by execution, and freezes the highest-scoring legal candidate after a finite search budget (Xu et al., 18 Aug 2026).

The expert specifies the search boundary rather than the final mechanism. Editable components may include thresholding and shrinkage rules, decay schedules, additional projection operators, singular-value processing, rank selection, low-rank projections, and observation-reliability estimation. Fixed elements include task-critical data-fidelity structures and interfaces.

Candidates are rejected if they violate observed-trace fidelity, alter the sampling mask, return non-real or non-finite output, diverge or fail to execute, change the fixed input-output interface, use test data, introduce unexplained free constants, or merely retune existing scalar values without changing the mechanism. Failed and rejected programs are retained as negative examples.

For noise-free interpolation, Evo-POCS adds a local phase-aligned dip-consistency correction to exponential hard-threshold POCS. The correction uses a direction bank, local phase estimation, residual-gated directional selection, and consensus prediction while retaining exact observed-trace restoration. Across missing ratios from 30% to 70%, Evo-POCS improves SNR over classical POCS by an average of 3.49 dB.

For simultaneous interpolation and denoising, Evo-MSSA discovers reliability-grouped MP–GD singular-value shrinkage. It divides Hankel columns according to local reliability, applies separate low-rank projections, and uses a reliability map to interpolate between noisy observations and low-rank estimates. Across five noise levels, Evo-MSSA improves average SNR by 7.15 dB over classic MSSA and by 3.31 dB over ODRR.

Unlike the recommender setting, the output of SeisEvo is not an agent system or a neural network. It is a frozen white-box algorithm that requires no agent, LLM, training phase, or neural network at inference time. This suggests an Evo-Rec design principle in which agentic search is used offline to produce an inspectable and deployable computational artifact.

5. Recoverability and safe self-evolution

Performance improvement alone is insufficient when an evolving system modifies persistent state. EvoUndo formalizes recoverability for self-modifying LLM agent harnesses, where a mutation may alter configuration, prompts, tools, routing, middleware, listeners, files, sockets, or other managed resources (Sah et al., 28 Aug 2026).

A candidate is represented as

$\mathcal{S}_t$0

where $\mathcal{S}_t$1 is the forward mutation, $\mathcal{S}_t$2 is a pre-state witness, $\mathcal{S}_t$3 is a recovery program, and $\mathcal{S}_t$4 is a typed effect contract. Recovery operates through

$\mathcal{S}_t$5

and succeeds when $\mathcal{S}_t$6 is observationally equivalent to the original state $\mathcal{S}_t$7 under $\mathcal{S}_t$8.

The recoverability criterion is counterfactual rather than nominal:

$\mathcal{S}_t$9

The framework distinguishes capability success from recoverability success. A mutation may improve the forward objective while failing to restore prior state under absent-versus-present keys, conflicting tool schemas, altered middleware ordering, resource contention, or other counterfactual conditions.

EvoUndo demonstrates two principal bottlenecks. Grounding concerns identifying the exact state surface that must be captured and restored. Expressivity concerns whether the recovery language can represent the required operation. In 600 unseen one-shot self-evolution tasks, 197 capability-positive mutations failed recoverability verification. Conventional repair under the original recovery language recovered 0/197. A deterministic oracle recovered 48/197 under $\mathcal{M}_t$0 and 191/197 under the extended language $\mathcal{M}_t$1.

On the oracle-defined $\mathcal{M}_t$2 stratum, exact-address diagnostics increased recovery from 0/48 to 38/48 when $\mathcal{M}_t$3 was already sufficient. On the $\mathcal{M}_t$4 stratum, extending the language increased recovery from 0/143 to 142/143 under coarse diagnostics. However, for gpt-oss-120b, exact diagnostics reduced recovery under the richer language from 142/143 to 133/143; this negative interaction was not reproduced by the Qwen3.8-27B replication (Sah et al., 28 Aug 2026).

For an Evo-Rec system that modifies production models, pipelines, prompts, tools, or infrastructure, these results suggest that every accepted evolution should include a typed effect contract, a pre-mutation witness, a constrained recovery program, and counterfactual verification. The proposed implication is architectural rather than demonstrated by EvoRec itself.

6. Evaluation, evidence, and limitations

EvoRec was evaluated on Amazon Books and an industrial dataset containing approximately 2.95 billion user–item interactions, 14.7 million users, and 20.1 million items. Reported metrics were Recall@5, Recall@10, NDCG@5, and NDCG@10. Baselines included SASRec, S$\mathcal{M}_t$5Rec, PinnerFormer, MGUI, Auto-MGUI, Evo-MGUI, HSTU, TIGER, Cobra, REG4Rec, Auto-REG, and Evo-REG4Rec.

The reported configuration used PyTorch, four NVIDIA A100 GPUs, Claude Opus 4.6 as the shared reasoning backbone, $\mathcal{M}_t$6, $\mathcal{M}_t$7, $\mathcal{M}_t$8, $\mathcal{M}_t$9, and verdict-balancing ratio $A$0. Reproduction with Qwen3.7-MAX produced consistent conclusions.

On Amazon Books, Evo-MGUI improved over the strongest ID-based baseline by 4.15% in R@5, 4.93% in N@5, 4.57% in R@10, and 5.54% in N@10. Evo-REG4Rec improved over generative-model baselines by 2.70%, 4.18%, 3.13%, and 3.48%, respectively. On the industrial dataset, Evo-MGUI improvements were 4.03%, 5.39%, 4.39%, and 4.44%, while Evo-REG4Rec improvements were 3.64%, 2.23%, 3.40%, and 3.33%. These are relative offline improvements rather than absolute percentage-point changes.

The ablation study on the industrial dataset reported an R@10 of 0.0571 for full EvoRec-MGUI, 0.0559 without Skill Evolution, 0.0551 without Memory, and 0.0562 without External Knowledge. The corresponding relative drops were 2.10%, 3.50%, and 1.58%. The study does not isolate every interaction: it lacks, for example, a direct comparison between multi-agent specialization and a single agent with equivalent context, or a complete factorial comparison of code/model co-evolution and model-only evolution.

A seven-day online A/B test compared production MGUI with EvoRec-optimized MGUI on an advertising recommendation platform operated by a leading Southeast Asian e-commerce company. Each group received 20% of users sampled uniformly at random. The treatment produced a 1.85% advertising-revenue lift and a 1.02% CTR gain, both statistically significant under a two-sided test with $A$1.

The evidence has important limitations. The paper does not provide detailed LLM-call costs, GPU-hours, failed-run overhead, exact prompts, retrieval interfaces, similarity-function definitions, verdict-assignment rules, or complete AutoML search spaces. Potential threats include dataset specificity, temporal nonstationarity, baseline comparability, multiple-experiment bias, attribution difficulty, limited LLM-backbone robustness, and the absence of a theoretical convergence guarantee. The online evaluation consists of one seven-day test and does not report confidence intervals, sample counts, variance estimates, detailed segmentation, or long-term effects (Mu et al., 15 Jun 2026).

SeisEvo similarly reports no conventional systematic ablation isolating each discovered component, and its search results depend on the seed algorithm, editable surface, objective, and physical constraints. It requires complete references for SNR- and SSIM-based search and does not establish global optimality or universal generalization (Xu et al., 18 Aug 2026). EvoUndo establishes empirical counterfactual recoverability rather than formal completeness, and its recovery languages remain specialized operational calculi (Sah et al., 28 Aug 2026).

7. Significance and prospective extensions

Evo-Rec’s principal significance is the integration of model evolution, algorithm discovery, persistent experimental memory, methodology distillation, external research retrieval, executable validation, and—by implication from recoverability research—safe admission of persistent mutations.

The framework differs from fixed-space AutoML because it can propose changes to losses, sampling procedures, architecture, attention mechanisms, optimization schedules, and other training components. It differs from a code translator because the Research Agent selects directions and the Skill Evolver converts accumulated trajectories into reusable methodology. It differs from ordinary rollback because recoverability requires state grounding, pre-state evidence, typed contracts, expressivity, ordering, and counterfactual verification.

A generalized Evo-Rec system could combine the following mechanisms:

• Executable evolution: evolve models, operators, or pipelines rather than only outputs.
• Structured Memory: retain successful, failed, and neutral trajectories with field-level retrieval.
• Skill distillation: convert multiple experiments into reusable methodology.
• Constrained program search: expose an explicit editable surface and reject illegal or non-executing candidates.
• Independent evaluation: use execution-derived metrics rather than LLM judgment alone.
• Recovery-aware admission: require witnesses, typed effect contracts, and counterfactual recovery tests for persistent mutations.
• White-box deployment: freeze the selected artifact so inference need not depend on an agent or LLM.
• External validation: separate search data from held-out evaluation data.

Future work identified for EvoRec includes multi-stage cascade optimization and cross-task Skill transfer across recommendation scenarios. The broader implications of SeisEvo suggest possible extension to other interpretable inverse-problem algorithms, while EvoUndo indicates that long-horizon Evo-Rec systems would require bounded recovery calculi, stable semantic addresses, effect tracking, concurrency and version semantics, security controls for witness stores, and compensation policies for irreversible effects.

These extensions remain proposed directions rather than established results. The demonstrated evidence supports Evo-Rec as a framework for iterative, memory-based, executable optimization and as a broader design pattern for evolving algorithms under explicit constraints. It does not establish universal open-endedness, global optimality, complete recoverability, or the replacement of human engineering expertise.