Automating the search for effective harnesses is an important step toward enabling agents to recursively self-improve. Existing harness optimizations typically produce a single global harness that is applied uniformly across task instances. However, a harness that works well on average may not be optimal for every instance. We introduce Turbo Harness, a framework that can adapt a globally optimized harness to each instance by reusing information generated during the original optimization process. Specifically, Turbo Harness recycles artifacts produced during a completed global harness optimization run, and summarizes them into a structured playbook. We train a harness editor to leverage this prior optimization experience to generate instance-specific patches to the global harness. At inference time, the editor uses the instance and the playbook to construct a tailored harness in which the execution model operates. Through numerical experiments, we show that Turbo Harness consistently outperforms existing harness optimization baselines across seven benchmarks spanning interactive agent tasks, software engineering, and long-horizon terminal tasks.
The Problem of Uniform Harnesses in Agent Self-Improvement
In many agent architectures, a "harness" refers to the combined set of prompts, constraints, evaluation criteria, and configuration parameters that guide how an agent interacts with a task. The harness defines what the agent sees, how it evaluates its own outputs, and when it should stop or succeed. Prior work on harness optimization has focused on finding a single set of these settings that performs well across a broad distribution of tasks. The resulting global harness is then applied unchanged to every new instance the agent encounters.
This uniform approach has a fundamental limitation: task instances vary in difficulty, structure, and the types of errors they provoke. A harness configuration that minimizes errors on easy instances may leave the agent ill-equipped for harder variants. Conversely, a configuration optimized for difficult instances may waste resources on simpler ones. The paper notes that a harness working well on average may not be optimal for any particular instance, let alone all of them. This trade-off motivates the need for adaptive harnesses that can shift their behavior per instance without requiring a full re-optimization from scratch each time.
From Global Configurations to Instance-Specific Tuning
The Turbo Harness framework addresses this gap by separating two phases: a one-time global optimization, followed by per-instance adaptation. In the global phase, an existing harness optimization routine searches for a broadly effective configuration. This process generates a wealth of intermediate data—loss trajectories, selected hyperparameter settings, per-instance performance snapshots, and other artifacts. Rather than discarding this information, Turbo Harness captures and structures it for reuse.
At the adaptation phase, given a new task instance, the framework must produce a harness tailored to that instance's specific characteristics. The key question is how to efficiently translate the stored optimization experience into a usable patch for the global harness. The paper introduces a learned component—the harness editor—that handles this translation. The editor is trained on the artifacts from many global optimization runs, learning to recognize patterns that indicate which modifications will be beneficial for which types of instances.
Artifact Recycling: Building a Playbook from Optimization Traces
Central to Turbo Harness is the concept of a "playbook." After a global harness optimization run concludes, the system collects all generated artifacts: the sequence of harness configurations explored, the performance measurements associated with each, the gradient or policy update signals that drove the search, and any distilled summaries of what worked across which families of instances. These artifacts are summarized into a structured playbook that serves as a compressed but informative record of the optimization journey.
The playbook is not a static document; it is a machine-readable schema that encodes what the optimization process learned about the relationship between instance characteristics and effective harness configurations. For example, it might note that certain prompt styles consistently reduce errors on multi-step reasoning tasks, or that specific temperature settings improve success rates on long-horizon planning benchmarks. By organizing this knowledge systematically, the playbook becomes the knowledge base from which the harness editor draws when faced with a new instance.
This recycling of artifacts is a form of meta-learning applied to harness optimization. Instead of each new instance requiring a fresh optimization run, the heavy lifting of discovering promising configurations has already been done. The playbook ensures that the insights from that prior work remain accessible and actionable.
The Harness Editor: Learning to Patch Global Configurations
The harness editor is the learning component of Turbo Harness. It takes as input the structured playbook and a description of the new task instance (which may include a natural language summary of the instance, its category, known difficulty markers, or even a few demonstration examples). The editor's output is a set of "instance-specific patches" — targeted modifications to the global harness that are expected to improve performance on the given instance.
Training the editor requires pairing many completed optimization runs with their corresponding playbooks and the final harness configurations that resulted. The editor learns a mapping from (playbook, instance description) to harness perturbations. These perturbations might adjust prompt phrasing, modify evaluation thresholds, reweight certain loss components, or activate/deactivate specific harness sub-modules. The editor is trained to produce perturbations that, when applied to the global harness, yield measurable improvement on held-out instances that were not part of the original optimization.
Importantly, the editor does not replace the global harness; it augments it. The global harness provides a solid baseline configuration that works reasonably well out of the box. The editor's patches fine-tune this baseline for the specific instance at hand. This separation ensures that the adaptation process remains lightweight and that the benefits of the original optimization are preserved rather than discarded.
Inference-Time Harness Construction from Instance and Playbook
When a new task instance arrives at inference time, the Turbo Harness pipeline proceeds as follows. First, the instance is described or summarized in a format compatible with the playbook schema. This description might be a short natural language prompt, a structured metadata block, or a vector embedding generated by a separate encoder. The playbook, which was produced during the initial global optimization, is retrieved from storage.
With both the instance description and the playbook in hand, the harness editor generates instance-specific patches. These patches are then applied to the global harness, producing a tailored harness for the current instance. The execution model—the agent or model that performs the task—operates within this adapted harness. Because the harness now reflects instance-specific adjustments, the execution model can leverage the optimized configuration without having been retrained from scratch.
This entire process occurs at inference time, meaning the additional computation is modest and occurs after the global optimization phase is complete. The paper emphasizes that this efficiency is a key practical advantage: the expensive global search need happen only once (or periodically), while per-instance adaptation is fast and requires only the playbook and the editor.
Benchmark Suite: Agent Tasks, Software Engineering, and Long-Horizon Terminal Tasks
To evaluate Turbo Harness, the authors conducted numerical experiments across seven benchmarks. These benchmarks span three major categories of agent workloads.
The first category consists of interactive agent tasks, where an agent engages with a user or environment in real time, receiving feedback and adjusting its behavior accordingly. These tasks test the harness's ability to adapt to quickly varying user expectations and input styles.
The second category is software engineering. In this domain, agents assist with code generation, refactoring, bug fixing, or other programming-related activities. The harness must accommodate the precise syntax requirements, logical reasoning demands, and style preferences that software tasks entail. The paper notes that harness adaptation in this domain is particularly challenging because the cost of errors is often high, and the space of possible configurations is large.
The third category comprises long-horizon terminal tasks. These are tasks that require the agent to execute many steps, maintain state across a prolonged interaction, and succeed only if it correctly navigates a sequence of subtasks. Examples might include multi-step planning, tool-use sequences, or complex data processing pipelines. The harness for such tasks must support sustained operation and error recovery over many turns.
Across all seven benchmarks—though the abstract does not list each benchmark individually—the consistent theme is that Turbo Harness outperforms existing harness optimization baselines. The baselines typically employ a single global harness applied uniformly, or perhaps simple heuristics for per-instance adjustment. Turbo Harness's instance-adaptive approach surpasses these in every benchmark domain, indicating that the playbook-plus-editor paradigm generalizes well beyond any single task family.
Outcomes Across Diverse Task Domains
The experimental results demonstrate that instance-adaptive harness optimization yields consistent performance gains. While the abstract does not provide exact numerical scores, it states that Turbo Harness "consistently outperforms existing harness optimization baselines across seven benchmarks." This uniform improvement suggests that the playbook and editor mechanism captures actionable regularities that apply whether the agent is chatting with a user, writing code, or executing a long-running pipeline.
The gains are particularly notable in the software engineering and long-horizon terminal task benchmarks, where the diversity of sub-problems and the length of required execution chains make a one-size-fits-all harness especially prone to suboptimality. In these domains, the ability to tweak the harness per instance translates to measurable reductions in error rates, faster task completion, or higher success probabilities.
In the interactive agent tasks, the adaptive harness enables more natural and effective user-agent interaction, as the harness can adjust to individual user phrasing styles, preferred levels of verbosity, and typical query patterns. These improvements, while perhaps more subtle in metric form, contribute to a more usable and satisfying agent experience.
Constraints and Design Trade-offs
The abstract acknowledges that existing harness optimizations produce a single global harness applied uniformly, and that this may not be optimal for every instance. From this, we can reasonably infer several trade-offs inherent in the Turbo Harness design.
First, the approach requires an initial global optimization run to generate the playbook. If the global search is poorly conducted, the playbook may contain limited or misleading information, and the editor's patches could be subpar. The quality of the final per-instance harnesses is thus bounded by the quality of the initial optimization.
Second, the harness editor itself must be trained, which requires access to multiple completed optimization runs and their playbooks. This training phase is a one-time cost, but it does require computational resources and diverse task coverage to produce an editor that generalizes well.
Third, at inference time, the editor adds a small but non-zero computational overhead. While the paper emphasizes that this overhead is modest compared to a full re-optimization, it is nonetheless present. In latency-sensitive applications, this additional step must be accounted for.
Fourth, the playbook is a structured summary, and like any summary, it necessarily discards some detail. Very fine-grained or idiosyncratic instance characteristics may not be captured, and the editor may miss opportunities for fine-tuned adjustments that a fresh optimization would discover. The paper's focus on consistent—rather than maximal—across diverse benchmarks suggests that the trade-off between adaptivity and completeness is acceptable for the targeted use cases.
These trade-offs are typical of any meta-learning or reuse-based approach, and the paper's contribution lies in demonstrating that the benefits of instance-adaptive harnesses outweigh the costs in the evaluated domains.