Self-Harnessing Recursive Language Models

2026-10-01T00:00:00+00:00

Authors</dt>

William Stanford, Mohammed Akram Khan Lodi</strong>, Jaloliddin Boymakhammadov, Eliaz Calvar, Simon Coumes</dd>

Venue</dt>

Submitted to the First Workshop on Meta Agents: Managing Agents that Manage Agents, NeurIPS 2026 (under review)</dd>

Program</dt>

Algoverse AI Research Program · Advisor: Dr. Simon Coumes</dd>

Timeline</dt>

July 2026 – present</dd>

Status</dt>

Infrastructure built · weakness mining running · proposal, validation and evaluation in progress</span></dd> </dl>
TL;DR</h2>
Recursive language models (RLMs) let a model with a bounded context window work over inputs far larger than that window: the model writes code that splits the input, calls fresh copies of itself on the pieces, and combines what comes back. In practice, plain RLMs fail in recurring, recognizable ways</strong>, and today those failures are fixed either by fine-tuning the model or by an expert hand-editing the harness.</p>
We adapt the Self-Harness</strong> framework of Zhang et al.</a> to RLMs, so that a fixed</em> model improves its own</em> recursive harness from evidence it produces while running:</p>

it mines</strong> recurring failure mechanisms from verifier-grounded execution traces,</li>
it proposes</strong> minimal edits to a small set of declared harness surfaces, and</li>
only edits that survive a non-regressive validation</strong> gate are promoted.</li> </ol>
The optimized harness is then frozen and evaluated on inputs 8–32× longer</strong> than anything seen during optimization, and on a different environment</strong> it never saw. No weights change at any point.</p>
Motivation</h2> Frontier models degrade on long inputs well before they hit their context limit, a failure mode known as context rot</em></a>. An input is in-distribution</em> when its length and structure resemble what the model reliably handles, and out-of-distribution</em> otherwise. Beyond that point, behavior degrades unpredictably.</p>
Recursive language models</a> scale inference-time compute instead of the context window. The model decomposes its own context and invokes copies of itself on the pieces, aiming to turn one out-of-distribution input into many sub-calls that are</em> in-distribution. Whether that works depends on the harness that governs the recursion</strong>, not just the model. Known failures implicate the harness directly:</p>

decomposition policies collapse into a single sub-call</strong> over the whole input;</li>
deeper recursion degrades accuracy</strong> while inflating cost;</li>
recursion halts by heuristic</strong> rather than evidence.</li> </ul>
There are three ways people fix this today:</p>
Approach</th> Limitation</th></tr></thead>

Fine-tune the model to work inside the harness</td> Any gain is tied to one checkpoint</td></tr>
Hand-engineer the harness</td> Needs repeated expert work, and a new model family can outpace it</td></tr>
A meta-agent edits the scaffold from its own trajectories</td> Not yet tested on recursive harnesses</td></tr> </tbody></table>
RLMs are a natural but untested setting for the third approach. Their failures are individually checkable</strong>, so a failure can be traced to a specific node in the call tree rather than to a proposer’s reading of a long trace. Recursion depth and sub-call decomposition are themselves things a meta-agent can modify.</p>

Research question.</strong> Can a language model identify recurring failures in its own recursive behavior, convert them into targeted harness edits, and build a harness that keeps performing on inputs longer than those it was optimized on?</p> </blockquote>
Background: the RLM turn loop</h2>
An RLM answers a query by driving a Python REPL turn by turn. On each turn the model writes one code block, sees only that block’s printed output, and works toward a final answer accumulated in a REPL variable. We call this sequence, from query to submitted answer, the turn loop</strong>.</p>
Three invariants of the reference implementation stay fixed throughout:</p>

Prompt-as-variable.</strong> The prompt lives in the REPL as a variable and is never copied into the root context.</li>
Programmatic sub-calls.</strong> Recursive calls to fresh copies of the model are issued by code</em>, in loops, over slices of the prompt variable.</li>
Outputs-in-variables.</strong> The final answer accumulates in, and is returned from, a REPL variable.</li> </ul>
Self-Harness edits the policies</strong> governing this loop, not the model. It acts through four runtime injection points (an injected metadata function, answer-protocol middleware, sub-call retry/validation, and enforceable batch caps), each of which defaults to the reference implementation’s behavior. The three invariants, the model’s weights, external tools, and the evaluator never change.</p>
Method</h2>
Ten editable surfaces</h3>
We declare ten editable surfaces</strong>, one per phase of the turn loop, each implemented as a single builder function the optimizer may rewrite. The surfaces are derived from the loop’s own phase structure rather than from a catalogue of known RLM failures, so anything the optimizer discovers can be credited to the loop rather than to a designer who already knew what to fix.</p>

</th> Surface</th> What it governs</th></tr></thead>

S1</td> REPL contract</td> The factual contract given to the root model: available names, answer protocol, per-turn REPL and stdout conventions, truncation behavior</td></tr>
S2</td> Decomposition instruction</td> Turns 1–2: how the root probes the input and whether/how it plans a decomposition</td></tr>
S3</td> Execution instruction</td> Per-turn discipline: what to print, when to offload to a sub-call vs. read directly, how to aggregate</td></tr>
S4</td> Verification instruction</td> What the root checks before marking an answer ready</td></tr>
S5</td> Recovery instruction</td> What the root does when a sub-call errors or returns something unusable</td></tr>
S6</td> Runtime policy</td> Numeric limits and switches: chars per prompt, batch width, call caps, recursion depth, retries, sub-output validation</td></tr>
S7</td> Metadata function</td> What carries across turns: the harness’s memory of prior calls</td></tr>
S8</td> REPL helpers</td> Harness-local functions injected into the REPL (chunkers, batch wrappers, …)</td></tr>
S9</td> Answer middleware</td> Programmatic inspection of the detected final answer, with the ability to redirect instead of accepting it</td></tr>
S10</td> Skills</td> Named, reusable procedures. Only a name/description index enters the prompt; bodies load on demand via load_skill(name)</code></td></tr> </tbody></table> </div> Optimization starts from a deliberately sparse initial harness H₀</strong>: most surfaces return nothing, a disabled policy, or a single generic line, and the skill library starts empty. Any orchestration strategy the tuned harness ends up carrying must therefore be recovered from the loop’s own execution traces</strong>, not inherited from H₀.</p> One surface is permanently excluded</strong>: the proposer may never truncate or pre-summarize the prompt variable into the root context. That would violate the prompt-as-variable invariant and turn the RLM back into a compaction agent.</p> One optimization round</h3>

Akram - recursive language models

Self-Harnessing Recursive Language Models