Harness-Specific LoRA Adapters Put Agent Training in Context

A coding model is only one part of a software agent. The surrounding harness supplies prompts, tools, control flow, timeouts, and rules for feeding observations back into the conversation. Change that wrapper and the same model can behave quite differently. A new community release on the Hugging Face Hub treats this variability as a training target: keep one base model, then train a small LoRA adapter for each harness.

The project covers pi, opencode, and hermes, with runs for LiquidAI's LFM2.5-24B-A2B and LFM3-1.7B plus an experimental run for webAI's TwIL-8B. Training uses GRPO through TRL's AsyncGRPOTrainer. Each policy learns on tasks with automated verification, while a safeagents proxy inspects proposed tool calls before the harness executes them.

Why the harness belongs in the training loop

A model trained on generic tool-use traces may know how to request a shell command, yet still struggle with a particular agent's tool schema or turn structure. Harness-specific training makes the actual runtime part of the learning environment. The policy sees the prompts, results, and stopping conditions it will encounter later rather than an approximation assembled in a separate pipeline.

LoRA makes that specialization comparatively lightweight. Instead of maintaining three full copies of a model, the system loads the base weights once and names a different rank-32 adapter for each harness. Trainers can update those adapters independently, and evaluation can serve many checkpoints beside the same base. The release reports this arrangement as an infrastructure advantage, but it also creates a useful product boundary: a team can preserve a general base model while swapping the relatively small policy layer that matches its agent runtime.

That boundary is not magic portability. An adapter optimized for one harness encodes assumptions about that harness's prompts and available actions. Moving it to a materially different runtime may erase the benefit or introduce surprising behavior. The meaningful comparison is therefore adapter versus base model inside the same harness, on unseen tasks, with identical budgets.

Verifiable work matters more than plausible output

The training mix combines data-analysis environments with 230 coding tasks reconstructed from shared agent trajectories. Those reconstructed environments classify work as repair, build, extend, or question answering and include an oracle plus a task-specific verifier. Forty reconstructed tasks and 150 data-analysis tasks are held out for evaluation.

This design gives reinforcement learning a concrete signal: did the result satisfy the verifier? It is stronger than judging whether a response merely looks like competent code. For build and extension tasks, teacher-generated hidden tests are checked against the original trajectory's completed implementation, a stub, an empty workspace, and injected faults before being accepted. Repair tasks reuse a failure that appeared and was subsequently fixed in the recorded session.

The current dataset also shows an important limitation. Of 270 reconstructed tasks, 253 are builds, while only 11 are repairs and six are extensions; none of the question-answering candidates survived into the release. A policy trained on that distribution may improve at greenfield construction without learning equally much about maintenance work. Evaluation results should be segmented by task family rather than compressed into a single success rate.

Guardrails are part of the objective

A verifier creates an incentive to pass, not necessarily to solve the intended problem. An agent might inspect hidden tests, alter grading files, retrieve a published answer, or bypass a network restriction. The safeagents proxy addresses that failure mode before execution. Its deterministic detectors examine each tool call, block high-severity patterns, return a notice to the harness, and assign zero reward to a rollout containing a blocked attempt.

This is a practical distinction from post-run auditing. A dangerous or invalid command does not need to execute before it is recognized. The published rules cover such cases as editing tests, writing reward files, seeking a task's source trajectory, accessing known answer stores, and exposing Hugging Face credentials. The release describes one TwIL-8B smoke-run attempt to locate the source bucket for a data task; the proxy blocked it at step zero.

Rule-based filtering still has costs. Broad patterns can reject legitimate work, and narrow patterns can miss new shortcuts. The team found one concrete collision when a detector for a grader path also matched a valid library a coding task asked the agent to create; narrowing the path resolved it. That episode suggests a recurring operational requirement: test guard plugins against representative clean trajectories, log both blocks and suspicious allowed calls, and version the rules with the environments they protect.

How to evaluate a harness adapter

Teams considering this approach should begin with a controlled baseline. Freeze the base model, harness version, task set, sampling configuration, time limit, and maximum agent steps. Then compare task success, calls per successful task, wall-clock time, blocked-call rate, and variance across repeated attempts. Efficiency claims are only useful when accuracy is held steady or improves; fewer calls from an agent that abandons difficult work are not a gain.

The held-out set must also resemble the intended workload without duplicating training trajectories. Break results down into builds, repairs, extensions, and analytical tasks, and inspect failures manually. A higher aggregate score can conceal regressions in the smaller categories. Because the release's final runs were being streamed as they progressed, checkpoint results should be treated as evolving evidence rather than a settled ranking.

Finally, keep the deployment unit explicit: base-model revision, adapter revision, harness revision, tool policy, and detector bundle. Reproducing agent behavior requires all five. Harness adapters are compelling precisely because they acknowledge that an agent is a system, not just a checkpoint; their evaluation and release process should preserve the same system-level view.