PaperlayerView exact revision on arXiv

Source-linked AI summary

Harness Self-Evolution for Long-Horizon Terminal Agents

Ruhan Wang, Yucheng Shi, Zongxia Li, Junyao Yang, Zhongzhi Li, Yue Yu, Haitao Mi, Dongruo Zhou, Leoweiliang

arXiv:2610.27435v1cs.AIcs.CL

TL;DR

Long-horizon terminal agents may solve a task once yet fail across repeated runs, leaving a gap between capability and reliable execution. RiseHarness iteratively improves harnesses for a fixed model using paired runs, internal execution evidence, and adapted external designs; experiments report improved average performance, consistency, and held-out transfer.

  • Problem

    Long-horizon terminal agents may solve a task once but fail across repeated runs, as errors can alter the environment and later context.

    Source: §1 · p. 1

  • Method

    RiseHarness contrasts successful and failed runs, combines agent trajectories with internal harness traces and a behavior-to-code Handbook, and adapts external designs for a fixed model.

    Source: §1 · p. 2

  • Results

    Experiments report improved average task performance and repeated-run consistency, while frozen evolved harnesses retain gains on an unseen benchmark and swapping harnesses between models reduces performance.

    Source: §5 · pp. 11–12

  • Takeaways & Limitations

    Frozen harnesses retaining gains on an unseen benchmark supports transfer of improvements to interaction mechanisms shared across tasks.

    Source: §5 · p. 12

    Discovery is limited to traceable flipping tasks; selected monitor boundaries and potentially stale Handbooks do not establish causality.

    Source: E Scope and Limitations · p. 37

Abstract

from arXiv · show

Long-horizon terminal agents may solve a task in one run yet fail across repeated runs. Stochastic errors can propagate through actions and context, creating a gap between capability and reliable execution. We present RiseHarness, a framework for iteratively improving agent harnesses with model weights fixed. It focuses on flipping tasks with both successful and failed runs under the same configuration, using successful runs as references for failure analysis. RiseHarness combines agent trajectories with internal harness traces from a runtime monitor to examine how model actions interact with command execution, feedback, context management, and completion decisions. A Harness Handbook links this evidence to harness behaviors and source code, helping identify recurring problems in mechanisms shared across tasks. RiseHarness then searches other harness frameworks for relevant implementations and adapts them as design references to the current model and execution protocol. Candidate changes undergo behavioral checks and repeated task evaluation; versions with measured gains seed the next iteration. This loop integrates suitable mechanisms from different frameworks into a single harness and uses new execution evidence to guide further changes. We evaluate task success and reliability across models, ablate harness execution evidence and external research, and test transfer to unseen benchmarks with the same model. RiseHarness treats a specific model as the unit of harness adaptation, studying how changes to shared interaction mechanisms can make existing capabilities more reliable across tasks.

1 Introduction

Long-horizon agents can succeed once yet fail across repeated runs, motivating harness improvements that keep model weights fixed. RiseHarness uses execution evidence and external implementations to develop and evaluate harness changes.

1 Introduction

  • RiseHarness addresses inconsistent repeated-run success by improving the harness around a fixed model.Stochastic errors can alter both the environment and later decision context.Source: §1 · pp. 1–2
  • Successful and failed runs under the same configuration are contrasted to identify behavioral needs and check them against actual harness execution.A runtime monitor aligns harness traces with agent trajectories, while the Harness Handbook links behavior to implementing code.Source: §1 · pp. 2–3
  • RiseHarness searches other frameworks for relevant implementations, then adapts designs to the current harness, runtime signals, and model behavior.The process considers required signals and interfaces before modifying existing mechanisms.Source: §1 · pp. 2–3
  • Behavioral checks and repeated task evaluations determine whether changes are retained, and accepted changes seed subsequent rounds.Model weights remain fixed throughout.Source: §1 · p. 2
  • The evaluation examines task success and reliability, the contributions of harness evidence and external research, and cross-benchmark transfer with the model held fixed.The supplied introduction describes these evaluation questions but gives no results.Source: §1 · pp. 2–3

2 Related Work

Related work spans long-horizon reliability, runtime harness design, and automated harness evolution. RiseHarness combines paired same-configuration runs, dual traces, a behavior-to-code Handbook, and external implementation research in its update process.

Long-horizon execution and success consistency

  • Long-horizon benchmarks and consistency measures distinguish repeated success from a single successful outcome, while failure-diagnosis work studies recovery and localization [1] [2] [3] [4] [19] [20].FIRE studies failure-informed runtime interventions for repeated success without changing model weights [11].Source: §2 · p. 3

Agent harnesses

  • Harness research treats command execution, observation construction, context management, and completion decisions as runtime mechanisms that can affect performance with a fixed model [7] [21] [22].Runtime records and implementation mappings provide complementary views of behavior and code [13, 23].Source: §2 · p. 3

Harness self-evolution

  • Prior automated harness-update methods use execution evidence and evaluation feedback [8] [9] [10], while ModularRSI and Self-Harness use successful-versus-failed runs or fixed-model edits [12] [33].HarnessEvolve uses successful references but generates and verifies them with ground-truth answers [34].Source: §2 · p. 4
  • RiseHarness combines same-configuration successes, dual traces, and the Handbook to check behavioral needs, then consults external implementations and evaluates transfer with the harness held fixed.The related-work discussion also notes matched-budget search baselines and held-out tests as evaluation considerations [37].Source: §2 · p. 4

3 Harness Self-Evolution

RiseHarness iteratively evolves a fixed-model harness using execution evidence, behavioral analysis, external design references, and repeated validation. Its process connects run-level observations to shared harness changes and retains candidates only when they meet configured checks and evaluation criteria.

3 Harness Self-Evolution

  • RiseHarness is a framework for evolving long-horizon agent harnesses using execution evidence and external design knowledge.Its method comprises recording and localizing behavior, discovering and grouping problems, researching mechanisms, and validating implementations.Source: §3 · p. 4

3.1 Preliminaries

  • The evaluated model, development tasks, protocol, verifier, and acceptance rules remain fixed; modifications are confined to harness prompts and executable interaction logic.The reference corpus contains outcomes and dual traces from repeated runs of the seed harness.Source: §3.1 · p. 5

3.2 Execution Evidence

  • Agent trajectories alone may not reveal how requests are dispatched or feedback is returned, so RiseHarness records internal harness traces and links them to agent traces.The Handbook maps behavioral responsibilities and triggers to functions and source code.Source: §3.2 · p. 5

3.3 Behavioral Analysis

  • For flipping tasks, successful and failed runs are paired to formulate behavioral wishes, which are checked against available information and executed mechanisms before findings are grouped.Groups are reviewed and prioritized by distinct-task coverage, distinct failing runs, and finding count.Source: §3.3 · p. 6

3.4 Design Exploration

  • Selected behavioral groups guide searches for relevant external implementations, which are adapted to the current harness structure, interaction protocol, and model behavior.Proposals specify implementation sites, dependencies, interaction costs, and expected outcomes; successful-task traces help assess possible disruption.Source: §3.4 · pp. 6–7

3.5 Validation and Evolution

  • Candidates undergo implementation and behavioral checks, screening, and repeated evaluation; adoption requires valid, complete records and an aggregate pass rate above the declared baseline.Accepted versions and their Handbooks and evaluation traces seed later rounds, while history guides subsequent repair or proposal search.Source: §3.5 · p. 7

4 Experiments

The experiments evaluate task success and repeated-run reliability across models, compare RiseHarness with baselines and component ablations, and test model-specific changes on a benchmark not used for evolution.

4.1 Experimental Setup

  • Evaluation uses two models, TBH for evolution and selection, and frozen harnesses on TB2.1 for transfer; tasks are run four times unless otherwise stated.The comparison includes Terminus-2, ModularRSI, AHE Harness, and ablations removing harness evidence or external research.Source: §4.1 · p. 8

4.2 Performance and Reliability

  • RiseHarness improves average success and repeated-run reliability over Terminus-2 across models; on TB2.1, GPT-6-sol gains 3.09% Pass@1 and DeepSeek-V4-Flash gains 3.09% Pass@1 and 6.74% Pass4.DeepSeek’s TB2.1 result uses its best observed three-mechanism version, while direct transfer of its final TBH-selected version is reported separately.Source: Table 1 · p. 9, §4.2 · pp. 9–10
  • On TBH, DeepSeek’s final version achieves the highest average pass rate and all-success task fraction while reducing flipping and all-failure tasks versus the seed; on TB2.1, the three-mechanism version ranks higher.TB2.1 was not used for evolution; its version ranking differs from TBH, where the four-mechanism final version performs best.Source: §4.2 · pp. 9–10, Figure 6 · p. 10

4.3 Component Contributions

  • Removing harness traces and the Handbook reduces DeepSeek performance: full RiseHarness gains 7% Pass@1 and 8% Pass4 on TBH and also outperforms the ablation on TB2.1.The ablation retains agent traces, source code, and the external-research procedure.Source: §4.3 · p. 10, Figure 5 · p. 10
  • Without external research, DeepSeek performs worse: full RiseHarness gains 5.50% Pass@1 and 6% Pass4 on TBH and also has higher average success and all-success task fractions on TB2.1.Both variants retain dual traces and the Handbook; they differ in whether proposals use external designs and implementations.Source: Figure 5 · p. 10, §4.3 · p. 11

4.4 Adaptation and Generalization

  • Retained interventions differ by model: GPT-6-sol changes session recovery, observation construction, and completion context, while DeepSeek-V4-Flash adds completion-evidence checks.Each model performs better with its own final harness than with the other model’s harness on both benchmarks.Source: Figure 4 · p. 10, §4.4 · p. 11, Figure 7 · p. 11

5 Conclusion

RiseHarness iteratively improves long-horizon agents’ harnesses with model weights fixed, retaining changes that improve task success and execution reliability. The conclusion reports model-specific interventions and gains on an unseen benchmark, while identifying broader validation and evaluation cost as future work.

5 Conclusion

  • RiseHarness contrasts successful and failed runs, combines trajectories with internal harness traces, and uses a Harness Handbook to guide model-specific changes.Behavioral checks and repeated evaluations determine whether changes are retained for subsequent iterations.Source: §5 · p. 11
  • Harness evolution improved average task performance and increased the fraction of tasks solved consistently across repeated runs.Ablations support contributions from harness execution evidence and external design research.Source: §5 · p. 11
  • Frozen evolved harnesses retained gains on an unseen benchmark, while swapping harnesses between models reduced performance.The retained changes targeted different behaviors and used different interventions across models.Source: §5 · p. 12
  • The authors identify evaluation across more models, task distributions, and frameworks, and reducing evaluation cost, as future work.Source: §5 · p. 12

A System Implementation

The supplied passages list the topics covered in the system implementation and model-specific adaptation appendices. They do not provide details of the implementation or adaptation procedures.

A System Implementation

B Model-Specific Adaptation

C Evaluation Methodology

The supplied passages list evaluation-methodology topics and identify a Scope and Limitations section, but do not provide their substantive content.

C Evaluation Methodology

E Scope and Limitations

A System Implementation

This section documents the implementation of a harness change for tracking independently checked failures and confirming them through matching successful reruns, including its evidence and version-management processes, behavioral checks, iteration rules, and signal limitations. It also evaluates the failure-only rejection check against a passing baseline and notes a rerun-dependent extra-turn risk.

A.1 Evidence and Versioning

  • Reference corpora pair task outcomes with agent and harness traces, while a Handbook maps recorded calls to behavioral responsibilities and implementing functions.Adopted candidates save source changes, settings, Handbook, recording configuration, evaluation outcomes, and traces together; rejected candidates leave the current version intact.Source: §A.1 · p. 16

A.2 Behavioral Validation

  • Behavioral validation uses mechanism contracts with trigger conditions, effects, hooks, state, settings, and dependencies, checking incumbent and modified behavior against frozen expectations.Contracts include positive, negative, and applicable recovery cases; finite checks cannot guarantee correctness on all tasks or isolate a mechanism that runs with dependencies.Source: §A.2 · p. 16

A.3 Iteration Management

  • Round history links proposals, checks, outcomes, and execution evidence to candidates, guiding repairs, revisions, alternatives, or renewed discovery.A round limit and policy bound iteration; only candidates passing configured checks and a valid, complete full evaluation under the aggregate pass-rate rule can be adopted.Source: §A.3 · p. 16

A.4.1 GPT-6-sol

  • In the HTTP scheduling example, a 24:00 boundary probe failed, yet the agent later declared the fixes verified.The passing run also rewrote an artifact without a matching comparison rerun, while the failing run accepted unrelated successes after invalid boundary parsing.Source: §02 · p. 17, §A.4.1 · p. 17, §01 · p. 17

03 Revision against harness execution

  • The harness could show an idle prompt but could not classify an earlier probe as failed or determine whether a later test resolved it.The shared requirement is to retain a failed comparison against its checked artifact and expectation, surfacing it at confirmation until a matching successful rerun clears it.Source: §03 · p. 18, §04 · p. 18

05 Search plan

  • The search plan found that combined tmux screen output lacks typed comparison results and artifact-version fingerprints, constraining what the candidate can verify.The candidate could use an out-of-band environment command for a new check, but its status cannot be attributed to an earlier tmux action; frozen framework components also constrain changes.Source: §05 · p. 19, §2 · p. 19

06 External precedent and local adaptation

  • The proposal adapts pytest’s persistent failed-test identifiers, but requires agent-specific checks and receipts rather than treating pytest as an agent completion gate.The appendix notes that the current fixture does not exercise the full ledger and that agent-authored checks may share the agent’s misreading.Source: §06 · p. 20

07 Generated proposal

  • The proposal keeps failed checks unresolved until the same check passes on the current artifact, withholding completion meanwhile.It specifies bounded, independently runnable checks, receipts and artifact fingerprints, a per-run ledger, and preservation of the existing confirmation path when no check can be built or no failure is recorded.Source: §07 · p. 21
  • The proposed failure-only rejection condition does not trigger on the baseline, but a failed spec-first rerun could add at least one turn.At episode 9, the agent claims task completion after prior validation and benchmark output, with no independently recorded failed check id.Source: §07 · p. 22

08 Implementation and evaluation records

This section documents a harness gate for checking confirming claims against readings recorded during a run and withholding completion for unsupported or unresolved values. It records the candidate’s results across 400 trials and describes a passing task in which the gate did not fire, along with a switch-off-compatible implementation.

08 Implementation and evaluation records

  • The independent-check receipt was not run; the implementation summary says only local parsing checks were performed, not benchmark or recorder runs.The full-confirmation receipt separately reports promotion_ready.Source: §08 · p. 22
  • Across 400 trials, the candidate passed 222 and had 2 runtime failures, versus the reference’s 201 passed and 15 runtime failures.Both arms were evaluated for 400 trials; the candidate receipt was marked promotion_ready.Source: §08 · p. 22

02 Pair-level wish

  • The pair-level wish treats repeated readings from an identical method as one observation and withholds standing until a differently parameterized reading is recorded.The failing run called its OCR values manually verified, while the passing run proposed tightly cropped OCR to resolve ambiguous digits.Source: §02 · p. 23

03 Revision against harness execution

  • The harness trace shows the failing run used one Tesseract command before asserting values, while the passing run used cropped, upscaled, thresholded OCR sweeps that yielded a different value.Both command lines were visible to the harness, but the trace shows no comparison or withholding based on method fingerprints.Source: §03 · p. 23

04 Shared behavioral requirement

  • The shared behavioral requirement is to withhold completion once when a claimed value rests on one method repeated with the same parameters or on unresolved disagreeing readings.The harness should return the conflicting readings to the run when it withholds release.Source: §04 · p. 24

05 Search plan

  • The search plan identifies the confirming completion claim as the intervention point, where a bare pending-completion boolean otherwise allows release despite single-method or conflicting readings.The candidate source lacks value extraction from observations, a per-run store pairing values with readings, and a defined method signature.Source: §05 · pp. 24–25

06 External precedent and local adaptation

  • The proposed adaptation maps audit-fence’s claim-to-source gate onto the harness’s recorded observations and completion claim, requiring new value-to-method pairing and a bounded withhold at the existing confirmation divergence.The withhold reissues confirmation and continues the loop, with at most one withhold per run.Source: §06 · pp. 26–27

07 Generated proposal

  • The generated proposal calls for per-run reading/value pairing, method normalization, and value-token extraction because the existing trace stores keystrokes and observations separately without those comparisons.Normalization is intended to ignore incidental text while distinguishing differently formed readings.Source: §07 · pp. 27–28
  • At a confirming claim, the proposed arm withholds once when readings show unreconciled values or only one method signature produced the claimed value; otherwise, it releases.The withhold extends the confirmation message and leaves pending completion set so the next consecutive claim ends the run as before.Source: §07 · p. 28
  • The gate derives method signatures and observed value tokens from trajectory steps and the captured claim, without requiring a new environment observation.The implementation would add helpers to pair dispatched keystrokes with observed values; its recorder reports the triggering reason only when the arm is enabled.Source: §07 · p. 29
  • Four stage-4.7 repeats passed; the run recorded 8 reports across 4 confirming claims, and the new arm did not fire on this stable passing run.The arm defaults off on the baseline; with the switch enabled, this run’s recorded comparisons did not meet its withhold condition.Source: §07 · p. 29

08 Implementation and evaluation records

  • The frozen unreconciled_reading_gate arm was implemented only in candidate_source/base_terminus.py, preserving the existing harness byte-for-byte when disabled.The implementation summary also notes a new runtime kwarg.Source: §08 · p. 29

08 Implementation and evaluation records (continued)

The records describe an unreconciled-reading completion gate, its trial counts and validation limits, and the prompts and implementation constraints used during harness adaptation. They also summarize three GPT-6-sol harness changes.

08 Implementation and evaluation records (continued)

  • The unreconciled-reading arm withholds completion once when readings are unreconciled, releases otherwise, and fails open when required information is missing.The decision uses method-signature and observed-value pairs; it runs no command, subprocess, or probe, and the bound is one withhold per run.Source: §08 · p. 30
  • 239 trials passed, 161 failed, and 7 had runtime failures; a separate scored-counts reference reports 230 passed, 170 failed, and 8 runtime failures across 400 trials.The two counts are distinct records, not a combined result.Source: §08 · p. 30
  • The GPT-6-sol candidate recognizes four predefined instruction patterns, independent behavioral checks were not run, and its selftests establish no conformance or performance claim.DeepSeek’s conflicting-readings branch has appendix limitations, and saved source citations do not establish an adaptation’s correctness.Source: §08 · p. 30

Proposal generation / saved message lines 5–6

  • Proposal prompts treat accepted wishes as hypotheses, require counterexample material and actual precedent searches, and call for configured local reads before search planning.The proposal stage specifies no implementation; a proposed mechanism needing a missing signal must produce it within allowed changes or be withheld.Source: Proposal generation / saved message… · p. 31

Implementation / complete shared instructions[0:14]

  • The implementation instructions freeze proposals and contracts, restrict code edits to candidate_source, and require the harness to remain unchanged while new arms are disabled.Every frozen arm must be implemented, with departures reported rather than hidden.Source: Implementation / complete shared… · pp. 31–32

Implementation / complete shared instructions[0:14] (continued)

  • Arms are judged by measured trial performance and recorder reports, with no conformance case; reports are required only for actual interventions, and infrastructure failures stay distinct from model verdicts.The instructions also prohibit actual benchmark runs during implementation.Source: Implementation / complete shared… · p. 32

GPT-6-sol / saved implementation-repair instructions

  • GPT-6-sol implementation repair requires fixing build-check failures while preserving frozen contracts, arm scope, and disabled-arm behavior.The repair instructions identify undefined names or import errors and trace-recorder failures as checks to address.Source: GPT-6-sol / saved… · p. 32

B.1 GPT-6-sol

  • GPT-6-sol changes add completion-history context, workspace diffs grounded in persisted files, and recovery that reports terminal-session state loss.The three mechanisms target completion confirmation, observation construction and output truncation, and interaction-loop session-liveness handling, respectively.Source: §B.1 · p. 33

B.2 DeepSeek-V4-Flash

This block details DeepSeek-V4-Flash’s bounded completion checks and the evaluation and reporting rules used for the supplementary results. It also describes a separate GPT-5.6-Terra command-transport modification.

B.2 DeepSeek-V4-Flash

  • Four checks extend the seed’s two-declaration completion handshake, each withholding completion at most once per run.They cover executable verification, designated invocation, observed outcome, and independent-reading corroboration; the command checks can overlap, while independent reading chiefly detects reliance on one method.Source: §B.2 · pp. 33–34

B.3 GPT-5.6-Terra

  • The GPT-5.6-Terra modification preserves literal tab characters as command data, addressing dispatch rather than completion confirmation.The passage says this experiment is reported separately and does not establish the changes needed by GPT-6-sol.Source: §B.3 · p. 34

C Evaluation Methodology

  • The evaluation-methodology supplement supplies scoring, baseline, and version-reporting rules, with numerical results in Appendix D.Source: C Evaluation Methodology · p. 34

C.1 Repeated Evaluation

  • With default r = 4, evaluation uses complete grids; valid completed runtime failures score zero, while missing, cancelled, or identity-mismatched measurements invalidate the grid.Aggregate outcome proportions cannot identify which initially stable tasks regressed; paired per-task outcomes are needed.Source: §C.1 · p. 35

C.2 Comparison Protocol

  • A candidate is adopted only after a valid complete evaluation exceeds its declared baseline; aggregate pass rate governs adoption, while reliability is reported separately.The comparison may reuse historical runs or use a newly measured incumbent control; historical reuse is the default, and aggregate gains may coexist with stable-task regressions.Source: §C.2 · p. 35

C.3 Result Reporting

  • Reporting distinguishes the TBH-selected final + IR version from the best-observed TB2.1 + OO version, which is selected using its TB2.1 score.The cumulative curves combine versions rather than isolating individual mechanisms, and the versions’ evaluation assembly differs in some cases.Source: §C.3 · p. 35

D Supplementary Results

  • Supplementary results extend the main experiments through trial counts, cumulative versions, ablations, cross-model transfer, and a separate earlier GPT-5.6-Terra experiment.Source: D Supplementary Results · p. 35

D.1 GPT-6-sol

  • Table 3 reports GPT-6-sol pass counts underlying Table 1 with the full 4N denominator; its ablations are unreported.Cross-model transfer measurements appear in Appendix D.4.Source: §D.1 · p. 35, Table 3 · p. 36

D.2 Evolution Results

The cumulative versions rank differently across the two benchmarks: the final + IR version leads on TBH, while + OO has the highest observed TB2.1 values. Direct transfer of the TBH-selected + IR version also improves both reported TB2.1 metrics over the seed.

D.2 Evolution Results

  • The final + IR version achieves the highest TBH Pass@1 and Pass4, while + OO has the highest observed TB2.1 values.Source: Table 4 · p. 36, §D.2 · p. 36
  • The reported results were above the seed by 3.09% and 6.74%, respectively.Source: §D.2 · p. 36

D.3 Ablation Results

The ablation section reports DeepSeek-V4-Flash ablations separately from the main comparison. It also describes cross-model transfer measurements and keeps earlier GPT-5.6-Terra results separate from GPT-6-sol.

D.3 Ablation Results

  • Table 5 reports DeepSeek-V4-Flash ablations; the full method uses + IR on TBH and + OO on TB2.1, with both ablations retaining the remaining components.Source: §D.3 · p. 36, Table 5 · p. 36

D.4 Cross-Model Transfer

  • Cross-model transfer applies each model’s final evolved harness to the other model, keeping the transferred harness fixed and evaluating each task four times on both benchmarks.This differs from cross-benchmark generalization, which keeps the execution model unchanged.Source: §D.4 · p. 37, Table 6 · p. 37

D.5 GPT-5.6-Terra

  • The earlier GPT-5.6-Terra results concern a different model from GPT-6-sol and are reported separately from its main-evaluation rows.The associated command-transport modification is described in Appendix B.3.Source: §D.5 · p. 37, Table 7 · p. 37

E Scope and Limitations

The paper identifies limits in the evidence used to discover changes, in candidate evaluation, and in the scope and cost of transfer. These limits constrain what the reported comparisons establish.

Execution evidence and analysis coverage

  • Flipping-task analysis excludes consistently failing tasks and failures that occur before trace recording; the monitor covers selected boundaries and the Handbook may omit or outdate behavior.Successful-versus-failed run differences may also reflect sampling, environment variation, or task difficulty, and neither evidence source establishes causality.Source: E Scope and Limitations · p. 37

Candidate changes and regression risks

  • External designs may require unavailable interfaces or signals, and finite behavioral checks plus combined-candidate evaluation do not isolate individual mechanisms.Aggregate-score adoption can retain changes that harm stable tasks, which aggregate proportions cannot quantify without per-task comparisons.Source: E Scope and Limitations · p. 37

Evaluation and transfer

  • Repeated development-set selection can exploit noise, and historical baselines are sensitive to service or environment drift; retained-score trends therefore require independent evaluation.Source: E Scope and Limitations · p. 37
  • Cross-model swapping shows model dependence for the tested harnesses, but does not rule out transfer of individual mechanisms between other models.Source: E Scope and Limitations · p. 38

Scope and resource costs

  • Other-harness use requires compatible monitoring, behavioral mappings, and evaluation adapters; the paper does not measure emissions or configured concurrency as speedup.The loop keeps model weights fixed and does not learn its outer controller; long runs, external research, and repeated evaluation incur inference and storage costs.Source: E Scope and Limitations · p. 38
Loading 2610.27435v1…