Mixture of Self-Improving Branches For Agent Harness Optimization

1 INTRODUCTION

• Fixed development sets and proposal instructions motivate adapting search, since fixed cases can overlook complementary strengths and fixed guidance cannot adapt exploration priorities.A harness may solve cases missed by leading harnesses yet rank lower overall, limiting further development of that capability.Source: §1 · p. 1
• Each branch retains cases where its leading harnesses have a relative advantage, drops cases solved by every branch’s leading harnesses, and adapts proposal guidance from local search experience.Guidance records successful and failed modifications and unresolved problems, directing later proposals toward branch-specific priorities.Source: §1 · p. 2
• A router chooses among development-best branch harnesses for each new problem because scores from branches with different development subsets are not directly comparable.Selection uses development data rather than unavailable test outcomes.Source: §1 · p. 2
• 34.8% and 5.2% relative gains on mathematical reasoning, 11.6% on Terminal-Bench 2.0, and 3.8% on SWE-bench Lite over Meta-Harness.The routed system improves across all four benchmark–model settings, with harnesses selected exclusively on development data.Source: §1 · p. 2

Self-evolving agents and harnesses

• Meta-Harness uses an agentic proposer and persistent filesystem to inspect implementations, scores, and traces, providing this work’s search framework and primary baseline (Lee et al., 2026).Other work explores automated harness optimization, online adaptation, and joint evolution of system components.Source: §2 · p. 2

Diversity through adaptive search inputs

• AlphaEvolve and AgenticGEO promote diversity by retaining alternative programs or rewriting strategies, whereas this work changes branch development sets through comparative frontier coverage.The task-level scoring rule remains fixed while different search objectives encourage complementary harnesses.Source: §2 · p. 3

Evolving guidance from search experience

• Prior optimizers refine prompts or programs from execution feedback, while DREvo and SkillOpt distill search evidence into guidance; this work makes proposal priorities branch-specific.Local successes and unresolved failures inform distinct priorities as branch objectives diverge.Source: §2 · p. 3

Deploying evolved harnesses

• Because search tasks can overlap with final evaluation, this work selects harnesses on development data and routes each input to a development-best branch expert.Branch-specific development scores are not directly comparable; routing approaches or exceeds the stronger branch harness without test-based selection.Source: §2 · p. 3

3 BRANCHING SEARCH WITH EVOLVING OBJECTIVES AND POLICIES

• Each branch is a separate search process with its own development subset, candidate history, and proposal guidance, initialized from shared seed harnesses, the full development set, and initial guidance.Candidate code, scores, and traces are stored in a branch-local filesystem; guidance is stored in SKILL.md.Source: §3 · p. 4
• A branch evaluates harness proposals on its current development subset and uses mean observed reward to select its highest-scoring candidate as the branch head.The objective is expected task reward over the branch’s current subset, with expectation over execution randomness.Source: §3 · p. 4
• For each case, frontier coverage counts how many top-q harnesses in each branch solve it; cases with a relative advantage are retained by that branch, while universally solved cases are removed.Subset changes can alter candidate rankings and frontier membership even when harness implementations remain unchanged.Source: §3 · p. 4
• Branch-specific proposal guidance evolves from local search records, distinguishing repeated evidence from isolated successes or failures as branch objectives diverge.The proposer can inspect execution traces and other artifacts and choose which failures to investigate under that guidance.Source: §3 · p. 4
• The router is trained on development cases solved by exactly one final branch head, using the successful head as label, and selects a head before execution without correctness feedback.It uses the action model, expert source code, head-exclusive cases, and both heads’ outputs.Source: §3 · p. 5
• The pipeline runs branches in parallel, begins pruning after each has at least q candidates, and constructs the router from final branch heads and development evidence.When subset and guidance updates coincide, subsets are updated first and both updated states are used in the next iteration.Source: §3 · p. 5

4.1 EXPERIMENTAL SETUP

• The evaluation spans Olympiad-level mathematics, terminal-based problem solving, and repository-level software engineering, using held-out tests after benchmark-specific development splits.The mathematical, Terminal-Bench, and SWE-bench settings use 250/200, 30/58, and 50/250 development/test tasks, respectively.Source: §4.1 · pp. 5–6

4.2 PERFORMANCE OF DEVELOPMENT-SELECTED SYSTEMS

• 34.8% on Math–Gemini 3 Flash, 5.2% on Math–Claude Sonnet 4.5, 11.6% on Terminal-Bench 2.0, and 3.8% on SWE-bench Lite are relative gains over Meta-Harness.Table 1 reports held-out performance for fixed baselines and development-selected systems.Source: Table 1 · p. 6, §4.2 · pp. 6–7

4.3 HOW BRANCHES DEVELOP DIFFERENT SEARCH TRAJECTORIES

• On Math–Gemini, Branch 1 develops answer checks and proof-obligation routing, while Branch 2 explores free-form derivation, closure, and agreement checks.Their proposal guidance prioritizes retrieved evidence in Branch 1 and restructuring derivations in Branch 2; at iteration 13, Branch 2 reduced its subset from 44 to 40 cases.Source: §4.3 · p. 7
• Development-selected branch heads solve complementary held-out cases across four settings, with combined coverage 4.0–9.0% above the stronger individual head.The router exceeds the stronger head by 4.0% on Math–Gemini and 1.7% on Terminal-Bench 2.0, but falls short by one test case on Math–Sonnet and SWE-bench Lite.Source: §4.3 · p. 8, Table 2 · p. 8, §4.4 · p. 8

4.4 ROUTER ANALYSIS

• Adding expert outputs to router examples raises Math–Gemini accuracy from 57.0% to 59.5%, but lowers Terminal-Bench 2.0 accuracy from 48.3% to 46.6%.Additional context therefore offers setting-dependent benefits; GEPA provides modest average gains across the tested input configurations.Source: §4.4 · p. 8

4.5 METHOD ABLATION STUDIES

• 62.0%, 56.0%, and 53.0% Math–Gemini accuracy correspond to development-subset updates every 1, 3, and 5 iterations, respectively.Longer intervals allow more proposals before observed differences between branches affect the search objective.Source: §4.5 · pp. 8–9, Table 3 · p. 8
• 62.0% accuracy with both development pruning and proposal adaptation exceeds 51.0% with neither, 50.0% with adaptation alone, and 54.0% with pruning alone.Proposal adaptation alone does not improve on independent search, but increases accuracy when pruning is enabled.Source: Table 3 · p. 8, §4.5 · p. 9

4.6 TEST PERFORMANCE ANALYSIS

• The test-best harness beats Meta-Harness in three settings and matches it on Math–Sonnet; on Math–Gemini, routing reaches 62.0% versus 58.0% for the test-best individual harness.Test-based selection raises Meta-Harness Math–Gemini accuracy from 46.0% to 49.0% and Math–Sonnet from 29.0% to 32.5%.Source: §4.6 · p. 9, Table 4 · p. 9

5 CONCLUSION

• Across four settings, development-selected heads with routing outperform development-selected Meta-Harness without test-based harness selection.The authors support adapting search objectives and branch-local proposal guidance together, then using development-informed routing to deploy complementary harnesses.Source: §5 · pp. 9–10
• Comparative frontier coverage changes each branch’s parent-selection objective, while separate skill documents preserve local priorities for later proposals.A recorded head replacement illustrates how this mechanism can redirect search toward a different harness family.Source: §5 · p. 9
• Unequal token usage and limited repeated evaluations constrain conclusions about efficiency and reliability; ablations do not establish that each trajectory change caused its subsequent test gain.Routing also falls slightly below the stronger individual head in two settings.Source: §5 · pp. 9–10

AI USE STATEMENT

• Generative AI tools assisted implementation, experimental feedback, analysis, interpretation, literature review, manuscript editing, and figure and code preparation, but not core methodology or research hypotheses.The authors state that they take responsibility for the final content and artifacts.Source: AI USE STATEMENT · p. 10

A TOKEN ACCOUNTING

• Task-solving tokens are 1.21×, 1.71×, and 1.50× Meta-Harness usage on the three benchmarks, respectively.The comparison uses two branches; the passage does not give the corresponding total-token values.Source: A TOKEN ACCOUNTING · p. 12, Table 5 · p. 13
• Task-solving usage sums input and output tokens across recorded evaluation calls, counting cached input once; authoring usage sums uncached input, cache-read, cache-creation, and output tokens.Total usage combines the task-solving and harness-authoring components.Source: A TOKEN ACCOUNTING · p. 12, Table 5 · p. 13
• Initial development pools contain 250 math cases, 30 Terminal-Bench 2.0 cases, and 50 SWE-bench Lite cases; pruning reduces later candidate evaluations.Task solving uses Claude Sonnet 4.5, while harness authoring uses Claude Opus 4.6.Source: A TOKEN ACCOUNTING · p. 12, Table 5 · p. 13

B.1 SUBSET HISTORIES ACROSS SETTINGS

• Subset updates normally begin at iteration 5 and require q = 5 candidate harnesses per branch; Math–Sonnet begins at iteration 6 after iteration 3 yields no candidate.Each branch’s active subset comprises shared cases plus those retained exclusively by that branch.Source: §B.1 · p. 13
• On SWE-bench Lite, shared cases fall from 30 to 24 and branch-exclusive cases rise from 1 to 7, while 19 cases remain removed from both branches.Across all four settings, the shared pool contracts as branch-exclusive cases increase; here the total retained pool stays unchanged.Source: §B.1 · p. 13

B.2 HOW SUBSET CHANGES REDIRECT HEAD SELECTION

• At iteration 13, after the subset loses four cases, a freeform derivation dual replaces the geometry-aware dual-solver as head.The subset had contracted from 58 to 44 cases between iterations 8 and 12 while the geometry-aware harness remained head.Source: §B.2 · p. 13
• The freeform derivation dual keeps retrieval paths, geometry-specific corpus selection, and conditional adjudication, but presents reasoning as ordinary prose and LaTeX rather than inside a JSON field.The change explores a less constrained derivation format after earlier attempts to impose additional solution procedures performed poorly.Source: §B.2 · p. 13
• Later heads combine free-form reasoning with targeted retrieval, then extend it through two-sided derivations, rehearsal, agreement checks, and gap-directed construction.At iteration 14, the freeform harness solves 8 of 40 retained cases versus 7 for an earlier progressive-refinement harness; the combined harness becomes head at iteration 15.Source: §B.2 · pp. 13–14

C.1 FULL UPDATE PROMPTS

• Branch-local skill updates compare supplied candidate outcomes, distinguish implementation-specific facts from tentative hypotheses, weight the latest validation stage, and set one objective without collapsing exploration.The instructions apply calibrated changes to each branch’s local skill file.Source: §C.1 · pp. 14–15
• Math and Terminal-Bench prompts use validation accuracy and pass rate, respectively, compare within the same validation stage, and treat missing evaluations as missing data.They also restrict edits to branch-local skill and gradient files and caution against treating one implementation as proof about a whole approach.Source: §C.1 · pp. 14–15

• P revises each branch’s proposal guidance from local search evidence.Source: §C.2 · p. 15
• The guidance updates are presented as SKILL.md diffs, with gray for context, red for deletions, and green for additions.Source: §C.2 · p. 15
• Using Appendix C.1 prompts, P revises St b from local search evidence, presenting branch-specific guidance updates for Math–Gemini, Math–Sonnet, Terminal-Bench 2.0, and SWE-bench Lite in Figures 4–7 as SKILL.md diffs.Source: §C.2 · p. 15

• The router input combines a GEPA-optimized instruction, expert source code, and head-exclusive development cases with both experts’ outputs.Source: §D.1 · p. 15
• The prompt repeats one decision-example block per development case, using solutions for math and final actions for Terminal-Bench 2.0 and SWE-bench Lite.Source: §D.1 · pp. 15, 18
• The router must return JSON choosing either expert_1 or expert_2 with a short evidence-based reason.Source: §D.1 · pp. 15, 18

D.2 ROUTER CONTEXT AND PROMPT ABLATIONS

• Among configurations without GEPA, all variants receive expert source code, while the compared inputs vary in included context.Table 6 compares three input configurations, each with and without GEPA-based prompt optimization.Source: §D.2 · p. 18
• Adding head-exclusive cases changes accuracy from 60.5% to 57.0% on Math–Gemini, from 30.5% to 30.0% on Math–Sonnet, and from 46.6% to 48.3% on Terminal-Bench 2.0.Source: §D.2 · p. 18
• Adding expert responses raises Math–Gemini accuracy to 59.5% but lowers Math–Sonnet and Terminal-Bench 2.0 accuracy to 29.0% and 46.6%.Source: §D.2 · p. 18
• All three configurations achieve 66.4% accuracy on SWE-bench Lite.Source: §D.2 · p. 18
• GEPA changes accuracy from 59.5% to 62.0% on Math–Gemini, 29.0% to 30.5% on Math–Sonnet, and 46.6% to 50.0% on Terminal-Bench 2.0, while SWE-bench Lite falls from 66.4% to 66.0%.Source: §D.2 · p. 18
• Averaged across benchmarks, GEPA yields small gains in all three input configurations, with its largest benefit from full context.Table 1 reports the full-context configuration with GEPA.Source: §D.2 · p. 18

E DISCOVERED HARNESS MECHANISMS

• The appendix describes harnesses underlying the test-best results in Table 4, selected from the ten-candidate pools defined in Section 4.6.Each description follows the execution sequence and identifies the main change from the preceding design.Source: E DISCOVERED HARNESS MECHANISMS · p. 18

E.1 MATH–GEMINI: CONSTRUCTION BEFORE ADJUDICATION

• 58.0% is the test-best score for the Math–Gemini gap-directed construction harness, which separates finding an attainable answer from establishing why no other answer is possible.Source: §E.1 · p. 18
• The Math–Gemini harness retrieves and rehearses worked examples, then uses separate solver calls to construct an attainable answer and derive necessary conditions.The construction step gives the adjudicator concrete evidence for resolving disagreements.Source: §E.1 · pp. 18–19
• When the normalized answers disagree, an additional call seeks an explicit construction or concrete check before a final call resolves the problem.When they agree, a further call challenges the shared answer.Source: §E.1 · p. 19

E.2 MATH–SONNET: CLEANED RETRIEVAL WITH ANSWER GROUNDING

• 32.5% test accuracy is reported for the Math–Sonnet clean-retrieval answer-grounding harness, which uses two retrieval-conditioned solution paths and conditional critique.Source: §E.2 · p. 19
• The Math–Sonnet harness cleans retrieved solutions, appends corpus reference answers, and returns matching normalized answers directly or uses a third call to critique disagreement.Its two paths retrieve geometry examples and distinct examples from the general corpus.Source: §E.2 · p. 19

E.3 TERMINAL-BENCH 2.0: VERIFICATION ONCE BEFORE COMPLETION

• The verification-once gate harness reports 50.0% task completion and modifies completion checks in a verification-enhanced Terminus-KIRA agent.Source: §E.3 · p. 19
• On the agent’s first completion signal, the harness requests verification; a later signal bypasses the gate, which remains closed after tool use resumes.Source: §E.3 · p. 19

E.4 SWE-BENCH LITE: ISSUE-GUIDED LOCALIZATION BEFORE EDITING

• The test-aware edit harness reports 66.4% issue resolution and adds a localization stage before the first model-driven action.Source: §E.4 · p. 19