Source-linked AI summary
Beyond Skill Evolution: Self-Evolving Context Management Policies for Long-Horizon Agent Harnesses
Weiyuan Li, Jinghan Xu, Aili Chen, Xintao Wang, Shuang Liang, Jiaqing Liang, Deqing Yang
TL;DR
Long-horizon agents can accumulate redundant context that buries useful information, while context management often remains fixed as task demands vary. ContextEvo reconstructs model-visible context from trajectories, diagnoses context-related failures, and updates policies; it improves full-benchmark results across three benchmarks and adapts policies to environment-specific information demands.
Problem
Existing experience- and skill-based methods are less effective on long-horizon tasks, and fixed or slightly adjusted context management limits adaptation as information accumulates.
Source: §1 · p. 2Method
ContextEvo reconstructs model-visible context at decision points, uses cross-case evidence and counterfactual replay to identify context-related failures, and applies constrained policy updates.
Source: §1 · p. 2, §4.1 · p. 5Results
3.1–4.4 percentage-point full-benchmark gains over Pi-agent under DeepSeek-V4-Flash across three benchmarks, with competitive performance against other harnesses.
Source: §1 · p. 2Takeaways & Limitations
Across reported settings, selected policies improve several full-benchmark point estimates over Pi-agent, and case analyses show different information demands across environments.
Source: §1 · p. 2, §7 · p. 9Cross-case evidence, bootstrap evidence, and decision-point replay do not by themselves establish task-level causal reward contributions for individual policy mechanisms.
Source: §7 · p. 9
Abstract
from arXiv · showhide
Harness evolution improves LLM agents by learning from execution trajectories, but existing experience- and skill-based methods are less effective on long-horizon tasks. As interactions grow, useful evidence can be buried by redundant or outdated context, making context management itself a key bottleneck. We introduce ContextEvo, a framework that learns a context policy from long-horizon trajectories. ContextEvo reconstructs the model-visible context at key decision points, identifies context-related failures, and applies targeted policy updates. Starting from the open-source Pi-agent harness, ContextEvo improves performance across three long-horizon task benchmarks, achieving results comparable to or better than several prominent agent harnesses, including Codex, OpenCode, and OpenClaw. Additional analyses show that fixed or locally evolved context strategies can fall short under long-horizon information pressure, while our methods adapt to the information demands of each environment.
1 INTRODUCTION
Long-horizon context growth can bury useful information, limiting existing experience- and skill-based harness evolution. ContextEvo evolves context policies using trajectory evidence, improving benchmark performance while adapting policies to environment-specific information demands.
1 INTRODUCTION
- In long-horizon tasks, redundant context can hinder skill invocation and degrade skill quality, while fixed or slightly adjusted context management limits adaptation across environments.Prior harness-evolution methods often add reusable rules, prompts, or skills (Alzubi et al., 2026; Zhang et al., 2026b; Yang et al., 2026; Agrawal et al., 2026).Source: §1 · p. 2
- Context-policy evolution must address both failure attribution—distinguishing context problems from model or environment failures—and identifying which policy component to update.These intertwined causes make context-policy effects difficult to identify and optimize (Zhang et al., 2026a; Li et al., 2026a).Source: §1 · p. 2
- ContextEvo reconstructs information flow, uses cross-case evidence and counterfactual replay to attribute failures to context management, then applies constrained policy updates.It evolves Input Assembly, History Maintenance, and Context Orchestration together.Source: §1 · p. 2
- 3.1–4.4 percentage-point full-benchmark gains over Pi-agent under DeepSeek-V4-Flash across three benchmarks, with competitive performance against other agent harnesses.The evolved policies also adapt to each environment’s information demands.Source: §1 · p. 2
2 RELATED WORK
Related work improves long-horizon agents through learning, harness design, and context-management methods, but systematic evolution of context policies across the information lifecycle remains unclear.
2 RELATED WORK
- Long-horizon agents use reinforcement learning and harness designs for execution guidance or history management, yet a harness designed in advance may not meet needs arising during a task.The paper studies evolving harness context management from execution trajectories.Source: §2 · p. 3
- Context-management research includes history organization, compact task states, memory operations, external stores, and feedback-refined compression rules.CONTEXTEVO instead uses trajectories to revise what enters context, how information is retained or transformed, and which models receive it.Source: §2 · p. 3
- Self-improving agents update playbooks, skills, memory, and other harness components, but growing histories can bury information and make useful skills hard to use when needed.Prior failure analysis and step-level replay do not resolve how to evolve context policies systematically across the full information lifecycle.Source: §2 · p. 3
3 PRELIMINARIES
The preliminaries define harness evolution with a fixed base model, describe context policies as information-management rules, and formulate policy evolution as reward maximization.
3.1 AGENT HARNESS EVOLUTION
- The paper studies harness evolution while holding the base model fixed and evolving the harness to improve agent performance.A harness defines execution procedures and determines the context available to the model.Source: §3.1 · p. 3
3.2 CONTEXT POLICY
- A context policy P maps information accumulated through time t—including instructions, observations, tool outputs, and intermediate information—to model-visible context c_t.The policy spans Input Assembly, History Maintenance, and Context Orchestration; these dimensions abstract the information lifecycle beyond particular components.Source: §3.2 · p. 4
- Table 1 presents common harness realizations across the three context-policy dimensions, whose implementations may be combined or modified.The dimensions are Input Assembly, History Maintenance, and Context Orchestration.Source: Table 1 · p. 4, §3.2 · p. 4
3.3 EVOLUTION OBJECTIVE
- The evolution objective is to identify a context policy that improves task-level reward under a fixed base model.An execution τ is generated under harness H_P with policy P, and R(τ) denotes its task-level reward.Source: §3.3 · p. 4
4 METHOD
CONTEXTEVO evolves context policies while keeping the base model fixed, using trajectory evidence to diagnose context-management failures and guide constrained updates. Its pipeline reconstructs information flow, attributes failures to policy dimensions, and updates the policy only when evidence supports doing so.
4 METHOD
- CONTEXTEVO uses long-horizon trajectories to identify whether failures arise from information management and which context-policy dimension should be evolved, while keeping the base model fixed.Supported diagnoses guide policy updates by modifying, combining, or introducing implementations along the identified dimensions.Source: §4 · p. 4
4.1 TRAJECTORY EVIDENCE RECONSTRUCTION
- Trajectory reconstruction scans full executions for information-processing events, then reviews successive segments while tracking progress, unresolved events, and context changes at relevant decisions.The running note links earlier information handling to later decisions and helps distinguish context failures from model, tool, or environment failures.Source: §4.1 · p. 5
4.2 FAILURE ATTRIBUTION AND TARGET IDENTIFICATION
- An analysis agent compares candidate decision points across successful and failed trajectories, using counterfactual replay when the evidence does not resolve attribution.Replay holds the execution prefix fixed and modifies only the model-visible context at the decision point; the local comparison tests the proposed update without side effects for subsequent actions.Source: §4.2 · pp. 5–6
- Attribution hypotheses identify an information failure type, its target policy dimension, and supporting evidence; only hypotheses that distinguish failed from successful executions are retained.Failure types are missing, degraded, buried, or polluted; dimensions are input, history, or orchestration.Source: §4.2 · p. 6
4.3 CONTEXT-POLICY UPDATE
- The policy editor may modify, combine, or introduce implementations, but unsupported evidence produces no update and leaves the policy unchanged.Allowed updates are subject to fixed safety constraints, and the updated policy generates trajectories for the next evolution round.Source: §4.3 · p. 6
5 EXPERIMENTS AND RESULTS
CONTEXTEVO is evaluated on three long-horizon benchmarks using two base models and improves full-benchmark performance against its Pi-agent starting point. It achieves strong comparisons with established harnesses, and the second evolution iteration improves over the first in all six benchmark–model settings.
5.1 EXPERIMENTAL SETUP
- The evaluation covers LHTB, DeepSWE, and BrowseComp-Plus, compares OpenCode, Pi-agent, Codex, and OpenClaw, and runs two evolution iterations with DeepSeek-V4-Flash and GPT-5.6-Luna.Results are reported on full task sets and separately on held-in evolution and reserved held-out evaluation sets.Source: §5.1 · p. 6
5.2 MAIN RESULTS
- 45.3% on LHTB and 71.7% on DeepSWE were the best full-benchmark scores under DeepSeek-V4-Flash; BrowseComp-Plus reached 88.5%, 0.6% below OpenClaw.Table 2 reports scores for held-in, held-out, and full task sets across harnesses and evolution iterations.Source: Table 2 · p. 7, §5.2 · p. 7
- Under GPT-5.6-Luna, CONTEXTEVO improved over the initial baseline on all three benchmarks and ranked second to Luna-native Codex on LHTB and BrowseComp-Plus, scoring 34.3% and 42.0%, respectively.Across models and settings, the paper reports performance comparable to established harnesses.Source: §5.2 · p. 7
- Iter-2 improved over iter-1 in all six benchmark–model settings; under DeepSeek-V4-Flash, LHTB rose from 44.8% to 45.3%, DeepSWE from 69.0% to 71.7%, and BrowseComp-Plus from 85.6% to 88.5%.The same direction held under GPT-5.6-Luna: LHTB rose from 31.0% to 34.3%, DeepSWE from 11.5% to 14.2%, and BrowseComp-Plus from 39.1% to 42.0%.Source: §5.2 · p. 7
6 ANALYSIS
ContextEvo outperforms static compression and local context adjustment across three long-horizon benchmarks, while skill-only evolution underperforms context-policy evolution on LHTB. The analyses show that policies adapt to environment-specific information demands, and that the complete evolution pipeline performs best in component ablations.
6.1 BEYOND SKILL EVOLUTION IN LONG-HORIZON TASKS
- Context-policy evolution reaches 0.448 reward with 7.52M tokens, versus 0.370 reward and 9.61M tokens for skill-only evolution.Adding skills to ContextEvo yields 0.419 reward with 9.69M tokens across 46 LHTB tasks.Source: §6.1 · p. 7, Table 3 · p. 8
6.2 CONTEXT MANAGEMENT BASELINES
- ContextEvo achieves the highest scores across all three benchmarks—0.142 on DeepSWE, 0.343 on LHTB, and 0.420 on BrowseComp-Plus—indicating full-policy evolution better addresses long-horizon context failures than static compression or local adjustment alone.Source: §6.2 · p. 8
6.3 LONG-HORIZON ENVIRONMENT-SPECIFIC POLICY EVOLUTION
- Learned policies emphasize selective observation handling and persistent execution state for LHTB, specification and verification continuity for DeepSWE, and recoverable evidence organization for BrowseComp-Plus.The analyses describe these as environment-specific policy realizations.Source: §6.3 · p. 8, Figure 3 · p. 9
- The LHTB policy transfers across DeepSeek and Luna within LHTB, but lowers performance on DeepSWE and has mixed effects on BrowseComp-Plus.The paper attributes this pattern to different context pressures across environments.Source: §6.3 · p. 8, Figure 3 · p. 9
6.4 COMPONENT ABLATION
- 44.78% for Full exceeds Native’s 41.66% by 3.12 percentage points; removing Paginated Trajectory Review lowers the overall score to 32.64%.The replay ablation also lowers held-out performance from 43.12% to 35.29%.Source: Table 5 · p. 9, §6.4 · p. 9
- ContextEvo improves OpenCode from 35.06% to 40.80% and OpenClaw from 18.97% to 45.40% on BrowseComp-Plus hard174.The reported gains are 10 tasks (+5.74 pp) for OpenCode and 46 tasks (+26.44 pp) for OpenClaw.Source: §6.4 · p. 9
7 CONCLUSION
ContextEvo evolves a context policy across three dimensions through evidence reconstruction, failure attribution, and constrained updates. Reported results improve several full-benchmark point estimates, while the evidence does not establish task-level causal reward contributions for individual mechanisms.
- ContextEvo evolves Input Assembly, History Maintenance, and Context Orchestration through evidence reconstruction, failure attribution and target identification, and constrained policy updates.The base model is kept fixed within each benchmark–model run.Source: §7 · p. 9
- Selected policies improve several full-benchmark point estimates over Pi-agent, while held-out changes vary by setting.Case-level analyses describe distinct information demands in terminal workflows, repository engineering, and multi-hop search.Source: §7 · p. 9
- Cross-case evidence, bootstrap evidence, and decision-point replay do not by themselves establish task-level causal reward contributions for individual policy mechanisms.Replay measures only local next-action sensitivity.Source: §7 · p. 9
AI USE STATEMENT
The authors report using generative AI tools to assist with result interpretation, literature organization, and drafting, editing, and formatting. They state that they reviewed and verified all AI-assisted outputs and take responsibility for the final content.
- The authors used generative AI tools for result interpretation, literature organization, and drafting, editing, and formatting, then reviewed and verified the outputs.They state that they take responsibility for the final content.Source: AI USE STATEMENT · p. 10
Task-family coverage
The benchmark-coverage figure inventories the benchmarks and their task-family composition, with different category breakdowns for LHTB, DeepSWE, and BrowseComp-Plus.
Task-family coverage
- The figure shows the benchmark inventory and held-in/held-out split, with task-family composition for LHTB, request types for DeepSWE, and a uniform multi-hop deep-research setting for BrowseComp-Plus.Source: Figure 4 · p. 15
A.1 BENCHMARK SETTINGS
The appendix describes three long-horizon benchmark settings and their task splits, then specifies the shared model, harness, and scoring procedures used for evaluation.
A.1 BENCHMARK SETTINGS
- LHTB spans software engineering, games, tool-use, multimodal work, and scientific or systems tasks; DeepSWE covers repository-level software-engineering requests; BrowseComp-Plus covers multi-hop deep-research questions requiring repeated retrieval and evidence synthesis.The BrowseComp-Plus subset contains 174 questions missed by both o3 and GPT-5 and requiring at least 30 o3 searches; seed 15 assigns 76 held-in and 98 held-out.Source: §A.1 · p. 15
- Workload profiles summarize tool calls, agent turns, and estimated trajectory text volume from frozen Pi/DeepSeek-V4-Flash traces.The text-volume measure estimates serialized analyst-visible text, not provider billing tokens.Source: Figure 5 · p. 16, Table 7 · p. 16
A.2 EVALUATION CONFIGURATION
- The experiments use shared model configurations and fixed harness settings, with one attempt per task and a 5,400-second timeout for reported runs.Baseline and self-evolved policies use the same harness settings within each comparison; confirmed infrastructure failures are rerun and replace the failed run.Source: §A.2 · pp. 16–17
- Scores are computed on fixed held-in, held-out, or full subsets, with task scoring based on benchmark-specific reward or verifier outcomes.Agent timeouts and agent-attributable execution failures receive zero; infrastructure-confirmed reruns replace the failed result before scoring.Source: §A.2 · p. 16
B METHOD DETAILS
ContextEvo represents context management as an executable policy across lifecycle intervention points and evolves it using trajectory evidence, screened attribution, replay, and constrained edits. Supplementary analyses distinguish evidence status and compare context-policy evolution with skill-only evolution.
B.1 CONTEXT-POLICY REALIZATION
- The context policy is realized as a ContextProgram within a fixed harness adapter, which maps runtime events to eight intervention points grouped under input assembly, history maintenance, and context orchestration.The adapter invokes points when their lifecycle events occur, and the resulting decisions shape the context exposed to the agent.Source: §B.1 · pp. 17–18, Table 11 · p. 18
B.2 CONTEXT-POLICY EVOLUTION
- The evolution run uses held-in trajectories for evidence review, attribution, replay, and policy selection, then freezes the selected policy before held-out evaluation.Runs are separated by benchmark and base-model block; an unsupported update may produce an empty changeset.Source: §B.2 · p. 19
- Deterministic case cards record entry and retention signals, while paginated review reconstructs full trajectories and the judge screens attribution hypotheses before the editor proposes policy changes.The judge can inspect aggregate evidence and replay a decision point; the editor may preserve the policy or return an empty changeset when evidence does not support a safe update.Source: §B.2 · pp. 19–20
- Attribution evidence supports different claim strengths: cross-case evidence can support attribution, local replay supports only decision-level sensitivity, and prospective evidence records a testable proposal.Replay changes the context at one decision point and measures next-action sensitivity, not a task-level counterfactual outcome; passing fixed screens alone does not establish a reward gain.Source: §B.2 · p. 22
C SUPPLEMENTARY ANALYSIS
- The appendix distinguishes observed, local, registered, and prospective evidence according to whether a behavior was exercised, changed a local decision, was available but unevaluated, or remains for future testing.These statuses qualify how policy-lineage evidence should be interpreted.Source: C SUPPLEMENTARY ANALYSIS · p. 23
C.1 SKILL-ONLY EVOLUTION AND CASE ANALYSIS
- In the completed LHTB comparison, skill-only scored 0.370, while ContextEvo combined with its corresponding skill bank scored 0.419; these aggregate scores motivate, but do not establish, case-level analysis.In one repository-change trajectory, local checks reached 22/22 correct queries and an approximately 2.09-fold speedup, but the required clean-tree application check was not completed; the case is evidence about a skill-only failure mode, not causal attribution.Source: §C.1 · p. 23
C.2 CONTEXT-MANAGEMENT BASELINES AND CASE ANALYSIS
Across context-management baselines and harnesses, the appendix reports benchmark scores, case analyses, and environment-specific policy behaviors. It also bounds the interpretation of those behaviors and describes transfer and reproducibility evidence.
C.2 CONTEXT-MANAGEMENT BASELINES AND CASE ANALYSIS
- On DeepSWE-113, LHTB-46, and BrowseComp-Plus hard174, ContextEvo scores 0.141593, 0.343056, and 0.419540, respectively, versus Pi-agent’s 0.132743, 0.303432, and 0.379300.The matched comparison uses GPT-5.6-Luna; ReSum and ACON are static compression baselines, while TACO is a frozen compression-only dynamic baseline.Source: §C.2 · p. 23
- The baseline case analysis tracks whether compression removes decisive evidence, whether TACO rules address held-in patterns, and how ContextEvo reconstructs evidence and updates policy.An analyzed configuration-semantics failure involved truncated entry evidence, buried history, and a stale state handoff.Source: §C.2 · p. 23
C.4 CROSS-HARNESS VALIDATION
- On BrowseComp-Plus hard174, OpenCode improves by 10 solved questions (+5.74 pp) and OpenClaw by 46 (+26.44 pp) under ContextEvo.Both comparisons use the same 174-question denominator; these are cross-harness method checks, not comparisons of native harness capabilities.Source: Table 12 · p. 24, §C.2 · p. 24, §C.4 · p. 24
C.3 REPRODUCIBILITY MATERIALS
- The paper’s supporting materials include source code, execution and evaluation scripts, fixed task splits, configuration and policy artifacts, and per-task results for reproducing the reported experiments.Source: §C.3 · p. 24
C.5 ENVIRONMENT-SPECIFIC POLICY EVOLUTION, CASE STUDIES, AND TRANSFER
- In LHTB, observations vary in value by content: source regions may need recovery, repeated logs may be reducible, and error lines, process state, or verification outputs can guide the next action.Inspected trajectories included 15 distinct new entry reductions across eight cases, and the resulting policy combines selective rendering, pressure-gated history maintenance, recent-state protection, and bounded records of facts and recovery paths.Source: §C.5 · pp. 24–25
- DeepSWE policy changes preserve specification provenance and verification obligations across edit–test–repair; individual interface contributions were not isolated by controlled ablations.The interfaces are implementation evidence supporting the mechanism interpretation, not independently measured sources of performance gains.Source: §C.5 · pp. 25–26
- BrowseComp-Plus policies preserve document-linked evidence and clue status, while bounded delegation separates branch-local search from parent synthesis; four calls across three tasks show use, not a causal reward gain.This policy responds to early decisive clues becoming harder to recover as later search results enter context.Source: §C.5 · p. 26
C.5.1 CROSS-MODEL AND CROSS-ENVIRONMENT TRANSFER
- The LHTB-evolved policy improves both base models in the same environment, but direct reuse on DeepSWE is negative for both and reuse on BrowseComp-Plus is mixed.Policy evolution both refines existing controls and can introduce interfaces such as grounding guidance, addressable recovery, and bounded delegation; these examples are not a closed list.Source: §C.5.1 · pp. 26–27