Harness-S trains agents with sibling harnesses on AppWorld, SWE-Gym, DBBench

Harness-S trains agents with sibling harnesses on AppWorld, SWE-Gym, DBBench

The paper, listed on Hugging Face Papers, starts from an observation about agent harnesses, the execution scaffolds that wrap a language model when it acts. When a harness is evolved from a common base, the authors say, the variants show three properties: Locality, Complementarity and Nonstationarity. Different variants repair different failures, and how useful each one is changes as the policy learns.

So instead of looking for one universally superior harness, the authors introduce Harness-S. It selectively rescues failures of a base execution system through "sibling" harnesses, then transfers the resulting capabilities into a single policy that remains effective under the original harness.

The method has several parts. Directional Harness Evolution builds specialized sibling harnesses along distinct repair directions. Together they form a reusable Sibling Harness Pool, which stays fixed during policy training. Complementary Harness Rescue Training then calls on that pool only when all initial attempts under the base harness fail. In that case the same policy generates fresh rollouts under selected auxiliary harnesses, and those trajectories replace the failed group for reinforcement learning.

An Adaptive Harness Router decides which siblings to use. It picks the Top-k variants using Harness Behavior Profiles and voting across multiple LLMs. Because a variant's usefulness shifts during training, policy-aware profile re-anchoring refreshes the router's evidence as the policy learns.

On results, the abstract says that across AppWorld, SWE-Gym and DBBench the trained policy substantially outperforms policy-only training when it is returned to the original base harness. Behavioral analyses and held-out cases, the authors say, support the idea that behaviors elicited by the harnesses move into the policy itself. Reusing the router for Rank-1 inference gives additional gains at the same executor rollout count.

Key facts

  • Harness-S uses sibling harnesses, variants evolved from a common base, to rescue failed rollouts during reinforcement learning.
  • The sibling pool is built by Directional Harness Evolution along distinct repair directions and stays fixed during policy training; it is invoked only when all initial attempts under the base harness fail.
  • An Adaptive Harness Router picks the Top-k variants using Harness Behavior Profiles and voting across multiple LLMs, with profiles re-anchored as the policy learns.
  • Across AppWorld, SWE-Gym and DBBench, the trained policy substantially outperforms policy-only training when returned to the original base harness.
  • Reusing the router for Rank-1 inference adds further gains at the same executor rollout count.

Why it matters

Agent performance depends on both the model and the harness around it, and improving a harness often means the deployed system needs that harness. Harness-S takes a different route: use harness variants as a training aid, then drop them. The goal is a single policy that stays effective under the original harness, so the extra scaffolding is not needed at the end. The paper's framing is that no single harness wins everywhere, because variants repair different failures and their value changes as the policy improves.

Who it affects

The work is most relevant to researchers training LLM agents with reinforcement learning, especially on tool-use and app-control tasks (AppWorld), software engineering (SWE-Gym) and database tasks (DBBench). Teams that maintain a fixed production harness and want training gains that carry over to it are the natural audience.

How to use it

The abstract gives the recipe in outline: evolve a pool of sibling harnesses along distinct repair directions and freeze it; during RL, run the usual attempts under the base harness; when every attempt fails, route to the Top-k siblings, generate new rollouts with the same policy, and swap those trajectories in for the failed group. Refresh the router's behavior profiles as the policy changes. At inference, the router can be reused for Rank-1 inference for further gains at the same executor rollout count. The abstract does not mention a code release.

How solid is it

This is a preprint, and everything here comes from its abstract. The headline result is stated only as the trained policy "substantially" outperforming policy-only training on three benchmarks; no percentages or scores are given. Behavioral analyses and held-out cases are cited as support for the claim that harness-elicited behaviors transfer into the policy. The abstract names no authors or institutions.

Risks and caveats

With no numeric results in the text, the size of the improvement cannot be judged. The abstract does not say which base policy or model was used, which LLMs vote in the router, the value of k, how many sibling harnesses are in the pool, or what the method costs in compute or training time. The gains are reported on three benchmarks, so how well the approach carries to other settings is not addressed in the text.

“Rather than seeking a universally superior harness, we introduce Harness-S to selectively rescue failures of a base execution system through sibling harnesses and transfer the resulting capabilities into a single policy that remains effective under the original harness.”

— Harness-S paper abstract