Paper Walkthrough: WHALE — Training the Weights and the Harness in Turns

An agent's performance is set by two things at once: the model weights, and the harness code wrapped around them. Polish one and the other becomes the ceiling. Here is a paper that dissolves that moving bottleneck by simply alternating two phases — explained from the metaphor through the math, the measured numbers, and the limits.

WHALE: A Simple Recipe for Joint Harness-Weight Optimization

A great sprinter in the wrong shoes

If you want a sprinter to run faster, are the legs the only thing to train? Spike length, the angle of the starting blocks — the setup outside the body matters just as much. And the awkward part is that each one moves the other's optimum. Stronger legs call for a different block angle; a different block angle recruits different muscles. Perfect one while freezing the other and you never reach what the pair could do together.

The same thing happens to LLM agents. The paper here is "WHALE: A Simple Recipe for Joint Harness-Weight Optimization" (Haechan Kim et al., arXiv:2609.00196, published 31 August 2026).

Its argument, in brief: agent performance depends jointly on the model parameters and on the executable harness code that manages context and control flow. Optimizing either in isolation leaves the system bottlenecked by its frozen counterpart — weight updates change which harness is effective, and harness updates change which model capabilities are exposed. Existing joint-adaptation methods optimize weights and textual prompts, but leave the broader harness fixed. So the authors propose WHALE (Weight-Harness Alternating LEarning): a simple recipe that alternates updating the model under the current harness with searching for a better harness under the updated model.

What exactly is a "harness"?

The paper's definition is crisp. The harness is the code that decides which observations enter the context, how tools are exposed and invoked, how execution errors are handled, and when an interaction terminates (§1). It covers system instructions, tool schemas, context management, parser and execution logic, and the termination policy (§3).

So the prompt is only one part of the harness. Prior work, the authors argue, has confined "everything outside the model" to text (§2). Their intuition pump makes it concrete: for a QA agent with a retrieval tool, stronger weights cannot use evidence that a brittle harness never retrieves, while better retrieval cannot help a model that cannot synthesize the returned evidence (§1).

There is only one objective: expected reward

Model parameters $\theta$ and an executable harness program $h$ together induce a distribution $\pi_{\theta,h}$ over trajectories $\tau$ — the sequence of model messages, tool calls and results, and environment transitions. Given a task distribution $\mathcal{P}$ and a verifier $R$, the system's expected reward is (§3):

Strip the notation away and it is a sentence which says "draw a lot of tasks, run the agent on each one, and average how often it gets them right." Here $x$ is an individual task, $\tau$ is the record of that run, $\pi_{\theta,h}$ is the distribution over such runs that the weights and the harness jointly induce, and $R$ is a grader that returns 1 for correct and 0 otherwise. Nothing in it is specific to weights or to harnesses — that is the point. There is a single number to be raised, and both components sit inside it on equal footing.

We want the pair $(\theta^\star, h^\star)$ that maximizes $J$ — but the paper does not maximize over $\Theta\times\mathcal{H}$ directly. It splits adaptation into a phase that moves $\theta$ with $h$ frozen and a phase that moves $h$ with $\theta$ frozen. This is the classical move known in optimization as coordinate descent (Wright, 2015): decompose a coupled problem into conditional updates, each taken against a fixed counterpart (§2).

Why not run both at once? Harness search operates on a long propose-and-accept cycle conditioned on many rollouts, while online fine-tuning interleaves rollout collection with gradient updates in small steps. The cadences do not match. Run them concurrently and every update is evaluated against a moving counterpart, which confounds credit assignment; avoid that, and you need synchronization barriers instead (§1).

What goes inside the two phases

Weight updates: online rejection-sampling fine-tuning (RSFT) (§3.1). Under a fixed harness, let the model generate its own trajectories, keep only the ones the verifier accepts, and run ordinary supervised learning on those. The rest are simply discarded. The experiments sample $G=8$ trajectories per prompt and maximize log-likelihood only over model-generated token positions, excluding user prompts and tool results.

Harness search: Meta-Harness (MH) (§3.2). An iterative propose–evaluate–select loop. At each iteration a proposer (Claude Opus 4.7 in the experiments) inspects the archived source files and the artifacts of past evaluations through filesystem tools, then writes $M$ candidate harnesses as code. Each candidate is scored, and the highest scorer across the whole archive is accepted. A proposal may refine an earlier candidate or revert to an earlier design.

WHALE itself is remarkably short

Cycle $k$ is just this (§4):

Read aloud, it is a two-step recipe which says: train the model a little under the current harness, then search the harness a little under the newly trained model, and repeat. The semicolons carry the whole idea — $h_k$ appears on the right of the first assignment and $\theta_{k+1}$ on the right of the second, so each phase is handed the other's latest result and never guesses at it. The key property is that WHALE requires only black-box interfaces to the two update procedures, so RSFT and MH can each be swapped for something else.