The Problem: Agents Waste Context Reconstructing the Same Control Decisions
Large language model agents solve tasks by interleaving model reasoning with external tools. In many deployments, an agent does not face isolated tasks. It repeatedly handles instances from the same task family, using the same model and tool interfaces. Although goals and observations change across instances, the surrounding control behavior recurs: the agent must refine queries, filter observations, verify progress, recover from errors, and decide when to stop. Standard agent harnesses, the executable code that orchestrates model and tool calls, either specify such behavior in advance or delegate all of it to the LLM. Repeated delegation preserves flexibility, but every decision incurs another inference call, grows the context window, and adds prompts, observations, and outputs to an ever-expanding execution history.
This is the central inefficiency that a team from the Shenzhen Institutes of Advanced Technology at the Chinese Academy of Sciences, along with collaborators from the University of Macau, aims to address. Their paper, "Grow the Harness, Not the Context," introduces a paradigm where task feedback turns recurring control behavior into reusable executable code, while reserving LLM calls strictly for task-specific semantic reasoning. The core thesis is structural: the harness acquires recurring control as persistent code, keeping model context reserved for evidence and decisions that vary by task.
Background: What Prior Work Missed
Existing agent systems have explored several approaches to managing control. ReAct interleaves reasoning and acting; Self-Ask decomposes questions into follow-up queries; IRCoT alternates retrieval with chain-of-thought reasoning. Reflexion carries feedback from earlier attempts into subsequent executions. Each establishes that the control surrounding an LLM is a substantive part of agent behavior, but their loop structures are specified before deployment, and many control decisions are represented as textual histories recomputed by the model as each trajectory unfolds.
Other work has attempted to amortize experience across tasks. ExpeL and Agent Workflow Memory store natural-language insights for later retrieval. Voyager, LATM, and CRAFT distill experience into executable skills or tools. While these show that behavior learned from earlier tasks can benefit later executions, textual artifacts must be retrieved and interpreted within the model context, and skills package individual behaviors behind an existing agent structure. Meanwhile, methods like AutoHarness and Meta-Harness optimize existing harnesses or synthesize code within prescribed interfaces and structures. But they start from a complete or partially complete controller, not a strategy-free scaffold.
The gap is clear. Prior work either keeps control in the model context, learns skills that must still be orchestrated by a fixed agent structure, or optimizes an existing controller. None starts from a scaffold with no predefined controller and grows the entire executable structure from task feedback. The authors call this starting point a "strategy-free scaffold": it exposes the required task, model, and tool interfaces but encodes no task-solving controller, such as a ReAct-style tool-calling loop.
The Method: How Growing Harness Works
Growing Harness is a failure-guided training paradigm. Training starts from a minimal executable scaffold that exposes the task entry point and fixed LLM and tool interfaces but contains no complete hand-designed agent strategy. Because it retains generic access to the model and tools, an LLM-mediated agent remains representable within the harness hypothesis class.
The process operates in rounds. In each round, the current harness runs on unseen tasks and maintains a bounded window of failures. For each failed execution, a function-level execution graph records the code paths, model calls, tool calls, and errors involved. An offline optimizer then receives the current harness, the traces of all active failures, and offline diagnostic artifacts. It produces a complete executable candidate that may modify only functions implicated by the failure traces and can add a small number of reusable helpers.
Three mechanisms make this work. First, function-level execution traces localize each failure to a bounded code surface. Rather than optimizing the entire program at every step, the optimizer edits only the entry function and functions directly invoked by the active failures, keeping each optimization step focused on a bounded execution slice regardless of the total program size.
Second, a failure-window curriculum maintains a bounded set of current failures and jointly repairs all of them. This encourages the optimizer to identify behavior shared across failures rather than patching instance-specific problems. Solved tasks leave the window; unresolved tasks retain fresh traces and incremented attempt counts. Tasks that exhaust their attempt budget are retired. The window refills with new failures as they appear.
Third, a success-first held-out gate protects against brittle or regressive updates. After every batch of repairs, the current harness is evaluated on a held-out gate set of tasks never seen during training. If gate success has degraded relative to the last accepted checkpoint, the entire repair sequence is rolled back, restoring not only the code but also the task cursor, failure window, counters, and training records. Only updates that preserve or improve gate success are accepted into the shared harness.
Accepted edits accumulate in one shared harness, so executable behavior learned from one group of failures can serve later tasks. Over successive rounds, the scaffold grows into a code-first, LLM-assisted agent without committing to a predefined controller. The optimizer is directed to implement deterministic, reusable operations like parsing, validation, state updates, and error recovery in code, while retaining LLM calls for semantic interpretation, synthesis, fuzzy comparison, and answer generation.
Experiments: Results Across Benchmarks and Model Scales
The authors evaluate Growing Harness on two distinct benchmarks: BrowseComp-Plus, a controlled benchmark for deep-search agents under a fixed retrieval corpus, and WebArena-Verified, an audited benchmark for reproducible evaluation of multi-step web agents. Both benchmarks use 200 training tasks, 50 held-out gate tasks, and 50 final-evaluation tasks. The trained harnesses are deployed on three LLMs spanning 4B to 120B parameters: gpt-oss-120b, gpt-oss-20b, and Qwen3.5-4B. Baselines include Tool-Calling (ReAct-style), Self-Ask, IRCoT, WebDreamer, and AgentOccam.
The results are striking across all six benchmark-model settings. On BrowseComp-Plus with gpt-oss-120b, Growing Harness achieves 49.3% success with only 6.0 LLM calls per task, compared to Tool-Calling's 40.0% success with 32.7 calls. That is a 76% reduction in LLM calls and an 87% reduction in cost. On WebArena-Verified with gpt-oss-120b, Growing Harness reaches 45.3% success with 3.8 calls, versus Tool-Calling's 30.0% success with 26.3 calls.
The most dramatic results come with the smallest model. On WebArena-Verified, Growing Harness maintains success rates of 44.7–45.3% across all three deployment models, while Tool-Calling collapses from 30.0% with gpt-oss-120b to just 6.7% with Qwen3.5-4B. Similarly, on BrowseComp-Plus, Tool-Calling achieves 40.0% with gpt-oss-120b but drops to 12.0% with Qwen3.5-4B, while Growing Harness sustains 29.3% with the 4B model.
The paper's central claim, that persistent program growth can move recurring control out of model context and into low-cost code, is directly supported by the numbers. Across all six settings, Growing Harness reduces LLM calls by 76.0–91.8% and deployed-agent inference cost by 74.4–98.6% relative to Tool-Calling. Despite using dramatically fewer calls, it improves mean success over Tool-Calling in five settings and remains within 0.7 percentage points in the sixth.
Ablations: What Each Mechanism Contributes
The authors isolate three principal mechanisms through controlled ablations on BrowseComp-Plus. Removing function-level guidance, which eliminates trace-local edit localization and the edit budget constraint, halves final success from 36% to 18%. Without function-level traces, the whole-program variant makes no gate progress for five steps before reaching a lower plateau, confirming that trace locality is what makes program search tractable.
Removing gate validation produces a more revealing failure pattern. Without rollback, gate success rises to 30% but then falls to 16%. The full method instead retains its best gate result once it reaches it. This directly demonstrates the failure mode that rollback targets: a repair can solve current failures while damaging behavior acquired earlier.
Finally, conditioning each edit on a single failure (window size K=1) lowers final success by 8 percentage points compared to the full method. This suggests that joint repair across a window of failures helps the optimizer identify behavior that generalizes across tasks, rather than patching individual instances.
Limitations and Trade-offs
The harness grows through offline optimization, which introduces a dependency on the optimizer model quality. The authors use a separate, more capable model (GPT-5.6-terra High) as the optimizer, which adds an offline cost. The paper does not fully characterize how the choice of optimizer affects growth quality or whether weaker optimers can still produce effective harnesses.
The approach also depends on the structure of the task family. The paper shows that BrowseComp-Plus produces a shared retrieval and verification pipeline, while WebArena-Verified grows a set of specialized handlers for diverse Shopping, Reddit, and Map tasks. If a task stream lacks sufficient shared structure, the learned harness may not generalize well. The paper acknowledges that the method's value depends on reusing the learned harness enough to offset the offline optimization cost.
Real deployment also raises concerns not fully addressed. The authors note that harness growth generates executable code that must be sandboxed, with explicit permission boundaries and validation of generated code. The gate validation mechanism provides some protection against regressions, but the paper does not discuss adversarial robustness or safety properties of the generated harnesses.
The experiments use relatively short task streams (200 training tasks). It remains open whether the approach scales to longer streams with more diverse task distributions, or whether the failure-window curriculum and gate rollback mechanism can handle the combinatorial complexity of very large task sets.
What This Means in Practice
For teams deploying LLM agents on repeated task streams, Growing Harness offers a concrete alternative to the prevailing approach of encoding all control as prompts inside the model context. The key insight is that recurring control behavior can be extracted from inference and compiled into persistent code, which executes at low marginal cost without consuming model context.
This has particularly significant implications for small models deployed on resource-constrained devices. The paper shows that a 4B-parameter model can achieve 44.7–45.3% on WebArena-Verified when paired with a grown harness, whereas the same model drops to 6.7% with Tool-Calling. The reusable code supplies recurring browser control that a small model would otherwise need to reconstruct during each execution.
The strategy-free scaffold design also means the approach does not require teams to hand-design a controller upfront. Training begins from a minimal executable seed and grows the control structure from task feedback. For organizations that have accumulated experience deploying agents across many similar tasks, the growing harness could provide a path to amortize that experience into a persistent, reusable artifact rather than encoding it in prompts or retrieved workflows.
The paper's broader contribution is a reframing of agent optimization. Rather than optimizing prompts, demonstrations, or workflows around a fixed LLM, Growing Harness treats the entire executable control structure as the learnable object. The LLM and tools remain fixed; only the harness changes. This structural approach to managing model context, where recurring control runs as code and only task-specific evidence flows through the model, represents a shift in how we think about efficient agent deployment.