RSIHub: A Composable Framework for Agent-Evolution Methods
Zimu Wang, Xiaobo Wang, Siyu Ye, Jiaqi Li, Silin Chen, Yuling Shi, Ruobing Wang, Jingjing Zhang, Chaofan Wang, Kai Wu, Mengnan Qi, Kai Cai, Xiaodong Gu, Zilong Zheng
RSIHub provides a modular framework for agent-evolution methods, separating experimental infrastructure from method-specific policy.
How can we decouple agent-evolution logic from the repetitive, error-prone infrastructure required to execute, evaluate, and track agent candidates?
Agent-evolution methods automate the improvement of prompts and tools, but researchers currently rebuild the same execution and evaluation machinery for every new experiment. RSIHub provides a shared, composable framework where researchers define evolution policies as interchangeable recipes while the framework manages candidate execution, lineage, and certified evaluation. On standard benchmarks, this framework supports effective agent improvement with gains of up to 13.5 percentage points, while providing a common protocol for comparing different evolution strategies.
Paper Primer
RSIHub separates method policy from the recurring mechanics of agent evolution. A recipe binds specific operators—such as Select, Mutate, and Gate—to a lifecycle, while the framework enforces boundaries on what the agent can modify and ensures evaluation remains outside the mutable surface.
RSIHub enables effective agent evolution across diverse methods and benchmarks.
The framework successfully instantiated four distinct evolution methods (AHE, Hyperagents, A-Evolve, and GEPA) without modifying the framework core. Observed pass@1 gains reached up to 13.5 percentage points on Terminal Bench 2.
The framework maintains experimental integrity by isolating evaluation from the mutable surface. It records candidate lineage and certified evaluation outcomes, preventing methods from gaming metrics by modifying the evaluation conditions themselves.
Why is a shared framework necessary for agent evolution?
Existing implementations bundle infrastructure (workspaces, runners, evaluators) with method policy, making it difficult to compare different evolution strategies without rebuilding the entire system from scratch.
Does RSIHub guarantee that an evolved agent is always better?
No; the authors observe that method rankings vary across benchmarks and seed agents, and gains on training tasks do not always transfer to held-out sealed tasks.
Researchers can now isolate and compare specific evolution policy components—like parent selection or mutation strategies—by swapping operators within a standardized, versioned experimental pipeline.
Motivation and Contribution
We expose the need for shared infrastructure and introduce RSIHub to decouple policy from plumbing.
Agent‑evolution methods repeatedly modify prompts, skills, tools, or orchestration based on execution feedback, yet each new method typically rebuilds the same workspace, runner, and evaluator plumbing.
Agent‑evolution is a loop that repeatedly selects a candidate agent, gathers evidence from its execution, proposes a revision, and retains the improved version for the next iteration.
To eliminate this duplication, we introduce RSIHub (Reusable System for Iterative Hub), a composable framework that abstracts execution, evaluation, recovery, and lineage into stable services while recipes encode the method‑specific policy.
The shift from custom‑built infrastructure to a reusable framework lets researchers concentrate on evolution policies rather than plumbing.
Prior Approaches to Agent Optimization
We survey prior agent‑evolution methods and supporting infrastructure, highlighting their focus and limitations.
Related work spans a spectrum of agent‑evolution strategies, memory extensions, and infrastructure platforms that inform our design.
Reflexion stores natural‑language feedback after each trial and re‑injects it on subsequent attempts, enabling the agent to learn from its own explanations.
Self‑Refine lets the model edit its own output at test time by prompting it to critique and rewrite the answer.
Introduces a communication channel that lets agents read/write a shared external memory, enabling persistent knowledge across episodes.
Methods that incorporate a model’s own reflections—self‑generated explanations or critiques—to improve subsequent performance.
Optimizes agent policies while explicitly modeling uncertainty in human preferences, reducing over‑fitting to noisy feedback.
Agents iteratively refine their own reward models based on observed outcomes, aiming to align learned rewards with true objectives.
Framework for optimizing language‑model programs by treating them as differentiable pipelines over textual variables.
Optimizes textual variables (e.g., prompts) using gradient information extracted from LLM outputs.
Evolves task and mutation prompts through a genetic algorithm, selecting high‑performing variants.
Evolves context playbooks—structured collections of prompts and tool calls—using a surrogate verifier to estimate quality.
Co‑evolves multi‑file skill modules together with a learned surrogate that predicts execution success.
Mines reusable code‑efficiency skills from execution traces, targeting reductions in runtime and resource usage.
Optimizes a graph of interacting GPT agents, coordinating their outputs to solve complex tasks.
Searches combinations of planning, reasoning, tool‑use, and memory modules to assemble high‑performing agents.
Integrates multiple optimizers to evolve workflows across several agents, handling coordination and data sharing.
Combines workspace inheritance with fresh conversational contexts and branch selection to diversify candidate exploration.
Frames deployment‑time adaptation as goal‑directed optimization over persistent system state, using reinforcement signals.
Guides revisions to harness files by distilling execution evidence into concise edit suggestions.
Uses trajectory reflection and Pareto selection to evolve prompts toward multi‑objective performance.
Combines a task agent with a self‑modifying meta‑agent in a single editable program, enabling joint evolution.
Revises optimizer scaffolding to improve convergence and stability of agent training loops.
Generates agent programs using a dedicated meta‑agent that proposes and validates code snippets.
Modifies its own coding agent by learning transformation rules from observed failures.
Evolves target algorithms themselves, not just their parameters, using a genetic programming approach.
Standardizes interfaces for tasks, datasets, agents, and container environments, enabling reproducible evaluation.
Offers composable abstractions for agents, tools, conversations, and workspaces, supporting both local and remote execution.
Classifies agent‑evolution research by measured gains, retention, and transfer performance on held‑out tasks.
Authenticate production steps, bind identities to signed artifacts, and package executions with dependencies for reproducibility.
The RSIHub Architecture
RSIHub isolates method policy from execution so researchers can focus on evolution logic.
Researchers building agent‑evolution pipelines spend most of their time wiring execution, logging, and checkpointing instead of designing the evolution policy itself. RSIHub removes that plumbing by fixing the execution mechanics and exposing only the policy slots.
RSIHub is like a kitchen where the stove (framework) stays the same, the recipe lists which ingredients (operators) to use, and the chef (outer agent) can rewrite the recipe between dishes without ever touching the stove.
How does RSIHub differ from a generic execution wrapper that simply runs scripts?
RSIHub goes beyond “run‑any‑script”: it enforces a strict lifecycle, validates operator outputs, isolates mutable‑surface edits, and records a certified evaluation that ties the candidate, its parent, and the exact recipe version together. A generic wrapper lacks these guarantees and would let a policy inadvertently modify evaluation fields.
Framework snapshots the recipe (Select=RandomParent, Mutate=NoOp).
Select picks parent candidate p from the archive.
Mutate receives p and, seeing an empty mutable surface, returns the unchanged child c.
Guardrail checks that c respects the empty surface (trivially true) and passes.
Evaluate runs the certified evaluation on c and records the result.
This toy run shows that the framework’s plumbing (snapshot, validation, evaluation) operates even when the policy does nothing, illustrating the clean separation between method logic and execution mechanics.
**Figure 1** RSIHub separates method policy from framework-managed execution. In a recipe-driven run, a researcher-authored recipe remains fixed across iterations. In an agent-driven run, an outer agent uses permitted feedback from each completed iteration to revise the recipe's operator bindings and policy settings for the next. At each iteration boundary, RSIHub validates and snapshots the active recipe before running the same guarded lifecycle. The target definition, evaluator, runtime, data splits, and mutable surface remain fixed; surface enforcement, protected evaluation, and verified archive writes stay under framework control.
Select – choose a parent candidate according to the recipe’s search policy.
Rollout – execute the parent on training tasks and collect execution evidence.
Analyze* – (optional) summarize rollout traces into a compact mutation hint.
Mutate – propose edits within the declared mutable surface.
Guardrail – verify that the proposed edit respects the mutable surface; optional Validate* and Novelty* may reject the proposal.
Evaluate – run a certified evaluation on the edited candidate and record the score.
Absorb – Gate decides whether the child becomes a new parent; Record writes method‑specific annotations; optional Reflect* extracts insights for future generations.
**Algorithm 1** One RSIHub candidate transaction. ``` 1: procedure EvolveOne(R, H) 2: p ← Select(H) 3: c ← ForkCertifiedParent(p, H) 4: X ← Rollout(c) 5: Z ← Analyze(c, X)* 6: Mutate(c, Z) 7: s ← CheckSurface(p, c, R_surface) 8: if Stops(s) then 9: return CloseAndRecord(H, p, c, s) 10: end if 11: v ← Validate(c)* 12: if Stops(v) then 13: return CloseAndRecord(H, p, c, v) 14: end if 15: n ← Novelty(p, H)* 16: if Stops(n) then 17: return CloseAndRecord(H, p, c, n) 18: end if 19: ĉ ← CommitReviewedTree(c) 20: q ← ResolveContract(R, ĉ) 21: y ← Evaluate(ĉ, q) 22: H ← Certify(H, p, ĉ, q, y) 23: if y.outcome ≠ benchmark_complete then 24: return H 25: end if 26: a ← Gate(p, ĉ, y, H) 27: if a.failed then 28: H ← CloseAndRecord(H, p, ĉ, a) 29: else 30: H ← AppendGateDecision(H, a) 31: e ← Record(p, ĉ, y, a, H) 32: H ← AppendAllowedRecord(H, e) 33: end if 34: Reflect(H)* 35: return H 36: end procedure ```
Provenance is captured by tying every certified evaluation to the exact recipe snapshot, parent commit, evaluator fingerprint, and task splits. This hash‑referenced contract makes it possible to separate method‑policy changes from evaluation‑condition changes in downstream analysis.
**Figure 2.** Inspecting one RSIHub execution. The read-only viewer identifies the accepted Generation 8 candidate as champion, shows its lifecycle status and run-specific primary-split and sealed scores, places it in the generation lineage, and summarizes its cumulative target-tree changes. The displayed values describe this execution; aggregate performance is reported in Section 4.
Table 1 enumerates five example recipes (`hill_climb`, aevolve, ahe, gepa, hyperagents) together with their search behaviors and mutation focuses, demonstrating how the same framework can host diverse evolution strategies.
Performance and Fidelity Results
RSIHub enables diverse evolution recipes while delivering strong agent performance across benchmarks.
We evaluate whether RSIHub can host a variety of evolution recipes and still deliver competitive agents on two distinct benchmarks.
RSIHub recipes improve MiniSWE on Terminal Bench 2 by up to +13.5 percentage points, reaching an overall pass@1 of 69.7 %.
Table 2 shows Hyperagents and A‑Evolve both achieve 69.7 % overall, a +13.5 pt gain over the MiniSWE seed.
**Table.** Performance comparison across benchmarks, agents, and methods.
**Results.** On Terminal Bench 2, both agents change by -2.6 points. MiniSWE's D-R agreement is 84.6%, compared with 83.5% D-D agreement. Codex has 82.0% D-R agreement versus 88.0% D-D agreement, yielding +6.0 points of excess disagreement; its RSIHub Avg@3 of 61.4 lies within the 60.7-65.2 range across the six direct executions. On $\tau^3$ Banking, MiniSWE and Codex change by -2.6 and +3.4 points, with excess disagreement of +0.2 and +2.1 points. Direct executions themselves disagree on 12.0-18.9% of tasks. These controls characterize execution variability; they do not establish execution-mode equivalence or the statistical significance of the single-run evolution gains. See Section B.1 for details.
RSIHub supports diverse evolution recipes without sacrificing agent performance.
Framework Fidelity and Boundary Enforcement
Ablations quantify how framework execution impacts fidelity and integrity.
The central premise is that a composable framework lets researchers focus on policy rather than plumbing. This section measures whether the framework’s execution matches a raw, framework‑free run and whether the system can recover from interruptions.
Execution fidelity quantifies how closely a framework‑mediated run reproduces the behavior of a direct run of the same frozen evaluator.
How is Execution Fidelity actually measured in these experiments?
We compute the agreement rate (percentage of tasks with identical outcomes) between Direct‑A and Direct‑B (D–D) and between each Direct run and the RSIHub run (D–R). The excess disagreement is the difference between the cross‑mode disagreement rate and the Direct‑Direct disagreement rate, isolating the framework’s contribution.
Across all benchmarks, the two independent Direct runs disagree on 12.0–18.9 % of tasks, establishing a baseline variability that the framework must not exceed. The excess disagreement values in the grid show that the framework adds at most a few points of mismatch.
**Table 3.** Fault-injection and boundary-enforcement results in two benchmark campaigns. Each correct-outcome entry is out of 30 trials; no trial admitted corrupted state. Latencies are reported separately rather than averaged across machines.
Extended Performance and Latency Analysis
Key results show negligible framework overhead and modest agreement gains.
Direct‑A–RSIHub yields a higher agreement with the framework‑mediated execution for Codex, while Direct‑B–RSIHub is better for MiniSWE on Terminal Bench 2.
Table 5 shows a +0.8‑point advantage for Codex (Direct‑A) and a +0.7‑point advantage for MiniSWE (Direct‑B).
The agreement analysis demonstrates that neither direct replication consistently matches the framework‑mediated execution, motivating the averaging strategy reported in the paper.
**Results.** On Terminal Bench 2, Direct-B-RSIHub agreement is 0.7 points higher for MiniSWE, whereas Direct-A-RSIHub agreement is 0.8 points higher for Codex. On $\tau^3$ Banking, Direct-A is 2.4 points higher for MiniSWE, while Direct-B is 1.4 points higher for Codex. Neither direct replicate is uniformly closer to framework-mediated execution, which motivates averaging the two comparisons.
**Results.** Workspace initialization was the largest measured operation in the $\tau^3$ Banking campaign, with a median of 1.23 seconds, whereas candidate snapshot creation and state verification were the largest regular operations on Terminal Bench 2, with medians of 0.76 and 0.65 seconds. These absolute latencies should not be compared directly across the two hosts. More importantly, framework work remained small relative to complete generations: 0.019% on $\tau^3$ Banking and a median of 0.02% on Terminal Bench 2. Model, mutation, and benchmark execution therefore dominate runtime in both measured workloads.
**Table 6.** Method-integration effort under the shared recipe and operator interfaces.
Lifecycle Operators and System Recovery
Defines lifecycle operator contracts and recovery semantics for RSIHub.
Recall that RSIHub abstracts execution and tracking so researchers can focus on policy rather than plumbing.
Lifecycle Operators are typed interfaces that each stage of a recipe must implement, guaranteeing that inputs and outputs are validated before the framework proceeds.
How are Lifecycle Operators different from ordinary function callbacks?
Unlike generic callbacks that merely invoke code, Lifecycle Operators declare a mode (required or optional) and a validated contract that specifies exactly which inputs are accepted and what result the framework will record, enabling automatic recovery, provenance tracking, and strict enforcement of execution semantics.
**Table 7** Lifecycle operator contracts. “Req.” denotes a registry-required operator and “Opt.” an operator enabled per recipe.
**Table 8.** Evaluation identity and the parent-selection predicate.
This table outlines recovery actions and their corresponding preserved properties based on various observed states in a system.
Recipe Implementation and Integration
Provides reusable recipe configuration and outlines limitations and responsible use.
RSIHub delivers open, reusable infrastructure that lets researchers focus on policy design rather than plumbing. All four evaluated adaptations reuse framework services without any source changes, yet performance gains and held‑out transfer differ across settings, underscoring the need for shared protocols and inspectable evidence for policy comparison.
The authors acknowledge several limitations: evidence guarantees depend on trusted framework services, host and filesystem protections, Git and digest operations, and valid evaluators. Consequently, the reported results apply only to the specific workloads, hosts, and lifecycle boundaries examined, and the task‑level agreement measurements do not capture full behavioral equivalence.
RSIHub can be misused to accelerate unsafe capability growth, reward gaming, or expose sensitive traces. Higher pass@1 scores do not imply safe deployment, and while the framework supports auditing and rollback, these mechanisms cannot undo external actions or disclosures. Deployers should therefore restrict filesystem and network access, exclude production credentials, and require held‑out safety evaluation plus human review before promotion.
Below is a representative GEPA‑inspired recipe configuration. It specifies experiment parameters, target definitions, a suite of operators (select, rollout, analyze, mutate, validate, gate, record), and evaluator settings for running the agent‑evolution loop.
Representative GEPA‑inspired recipe configuration (comments explain each section).