A better model still matters. But for the AI systems that work across a large repository, long-running task, or messy tool environment, the harness increasingly decides whether that capability becomes useful engineering work or a long, expensive transcript.
Ask a coding agent to migrate a deprecated authentication library in a large repository and it can look brilliant for the first few minutes. It reads the package manifest, finds imports, opens tests, runs a command, sees a failure, reads more files, proposes a diff, runs another command, and tries again.
Then the session gets heavy. Repository guidance, source files, package metadata, test logs, shell errors, diffs, prior plans, and retry notes all compete for the next decision. The model has more information than it started with, but not necessarily a clearer job. A bigger context window delays that problem. It does not decide what deserves the model's attention right now.
That is why the next practical advantage in AI systems will not come only from choosing a stronger model. It will come from the system around the model deciding how the work is shaped.
A harness is more than tool-call management
Most developers first think of a harness as the thing that manages tool calling for the model. You define a few tools, describe their arguments, let the model choose one, run it, and send the result back. If the model can search a repository, run a test, or call an API, the harness can look like the thin adapter that turns an LLM response into an action.
That is a fair first impression. Tool calls are the visible part. But a useful agent has already made several other decisions before it reaches the exciting moment where it runs a command.
Which repository instructions should this call see? Which files are relevant enough to load now? Should a failing test log remain raw evidence in a store, become a short finding with a link back to the log, or be pasted into the conversation? Is this a job for one model call, a small investigation delegated to another call, or ordinary software such as a file search and version comparison? What must be checked before the agent edits a file, retries, or tells everyone the migration is “done” — a word that has caused more meetings than it has ended?
The harness is the system that answers those questions. It manages more than the tool call itself: it manages the model's working view of the task, the state that survives between calls, the handoffs between steps, and the checks that turn an answer into an acceptable action.
Model weights
+ harness
+ external state
+ tools
+ verification
= system behaviour
Tool calls belong inside this picture, not at its centre. A tool tells the model what it can do. The harness decides what the model sees before it decides what it wants to do, how the result changes system state, and whether the next step is even allowed.
This matters because a model does not experience a repository, an incident, or a research corpus directly. It experiences the slice of that environment the harness has assembled. Once you see that, a useful next question follows: can changing that setup change how well the same model handles a bigger or unfamiliar job? That is the question behind the research.
Researchers tried the same model in two work setups
That claim is the premise behind a July 2026 technical article by Alex L. Zhang and Omar Khattab, *Language model harnesses are compositional generalizers* . It is promising early research published by its authors, not a peer-reviewed result or a production coding-agent test.
The paper asks a practical version of that question: can a model reuse a procedure it has already learned when the new task looks different on the surface?
Imagine a job that needs the same sequence every time: inspect a collection, split it into manageable parts, classify each part, combine the result, and check it. The next job may involve different files, words, or data, but it may still have that same sequence underneath. Reusing a familiar sequence on a new mix of details is what the researchers mean by compositional generalization. You do not need to memorise the phrase; the useful idea is “same kind of work, new material.”
To test it, the authors used the same underlying Qwen3-30B-A3B-Instruct-2507 model in two work setups.
| Work setup | What happens in plain language |
|---|---|
| The familiar direct setup — called the base Transformer in the paper | Put the task material into the model's context and ask the model to work it out from there. As more tool output and task detail arrive, the model must make sense of that growing pile. |
| The RLM setup — short for Recursive Language Model | Keep the large task material in a separate working area, such as an execution environment that can store files, lists, and results. A central model can inspect only the relevant piece, assign a focused model call one small question, and bring back the result it needs next. |
Think of two project teams tackling the same migration. In the first team, the coordinator joins every meeting carrying every raw document, chat message, error log, and status update. In the second, the coordinator has a task board: people investigate specific questions, evidence stays attached to the work item, and the coordinator receives a short report when a decision is needed. Both teams have the same coordinator. Only one has decided that not every status update needs a seat at the executive meeting.
That is what changed in the experiment. The researchers trained both setups on short tasks, then tested them on versions reported as 8–32 times longer across six test settings. They summarise the result as roughly ten times the improvement on the longer tests for comparable improvement during training, and report stronger transfer across three pairs of tasks from different domains that used a similar work sequence. In plain language: when the surrounding setup kept the central model's job familiar, the model appeared better able to reuse that job as the task became longer or changed subject.
The result is interesting because it does not say “the RLM had a smarter brain.” The underlying model was the same. The work setup changed what the central model had to hold in its immediate context and how it could get to an answer.
It is also not a blank cheque for recursive agents. The reported RLM training took roughly 1.5–3 times longer than the direct comparison, the experiments used one kind of underlying model and tasks that split naturally into parts, and one setting benefited from an explicit nudge to split the task. The researchers also compared each new run with earlier runs using basic measures such as how similar their text and length were. That is a useful clue that the system may be reusing a familiar pattern; it is not proof that two different tasks are truly the same. The evidence is strong enough to take the harness seriously, not strong enough to declare the problem solved.
How the RLM setup changes a model call
The paper's central design move is easy to miss because it can sound like ordinary context management. It is more deliberate than “make the prompt shorter.”
In a conventional agent loop, the central model often sees a growing history:
Task + files + tool output + sub-agent output + retries + diffs + test logs
↓
next central-model decision
In the RLM setup, the large input, intermediate lists, raw worker outputs, and task state can remain outside the central model's conversation. The central model gets a handle to inspect the relevant material — a repository map, a file path, a stored list, or a search result — rather than receiving everything at once. It can assign one model call a focused question, such as “find every use of this deprecated method,” then retrieve the result needed for the next decision.
It can also use ordinary deterministic software: a tool that gives the same result for the same input. A file search can collect every import of a library into one list. A version comparison can show which modules use an older dependency. A test runner can report which checks passed. Those are jobs where the model does not need to improvise a summary from a pile of text; software can do the bookkeeping exactly.
This is not about hiding information from the model. It is about giving the system a deliberate information boundary. The central model can still inspect the raw evidence when it must. It just does not have to carry every raw artifact through every later decision.
The paper calls the goal locally in-distribution. The plain version is simpler: even when the whole job is long or unfamiliar, give each model call a small, clear job with the evidence it needs. Before the next call, ask whether it has a defined question and a bounded evidence set — or whether it is being asked to reconstruct an entire system history before it can move.
Bring the idea into a real repository
The research did not test a repository migration, so the following is an engineering inference, not a result from the paper.
Return to the authentication-library migration. A context-heavy agent might start by pulling broad repository instructions, many files, package metadata, every search result, command output, failed test, and partial diff back into its main history. It may eventually make the right change, but the root model is continually re-reading task-specific debris while deciding what to do next.
An RLM-inspired harness would give the coordinating model — the “root” model in the paper's terminology — a different job. It would receive the migration goal, a repository map, safety boundaries, and acceptance criteria. Focused model calls could answer narrow questions: Where is the deprecated library imported? Which call sites use the affected API? Which modules have tests? What does the replacement library require?
Each answer would be stored as a structured record with links back to the files, commands, or test output that support it. Ordinary software could collect all imports into a module-by-module list or compare the current and replacement dependency versions. Before the coordinating model chooses the next change or raises a risk, it would receive a short decision packet: the affected modules, the evidence found, the checks that passed or failed, and anything still unresolved. “Verified” does not mean magically correct. It means the packet includes the checks and sources that support the decision, so nobody has to accept a confident paragraph on vibes alone.
Migration request
│
├── Before: root history absorbs files, logs, retries, and diffs
│
└── After: root coordinates focused investigations
│
├── repository map and dependency uses
├── migration constraints and change clusters
├── targeted tests and verification results
└── verified decision packet for the next move
This will not make every migration easy. Deeply coupled failures, unclear requirements, weak tests, unsafe permissions, and a bad way of splitting the work can still defeat the workflow. A harness can also add latency, cost, and new places for errors to compound. That is why the redesign must include tools limited to the permission they need, traceable intermediate findings, local checks, and human gates where the risk requires them.
But it changes the right design question. Instead of asking, “How do we give the agent more context?”, ask, “What is the smallest reliable context and evidence packet for this decision?”
The future advantage is harness engineering
This shift is already visible outside the research article. OpenAI describes the Codex harness as the agent loop that coordinates the user, model, tools, execution, and what fits in the model's working memory. Its harness-engineering account describes repository knowledge, feedback loops, review, and verification as part of getting agents to complete engineering work. Anthropic's context-engineering guidance describes loading context only when needed, summarising a conversation before it becomes unwieldy, and giving separate focused model calls clean briefs. Its Managed Agents design separates the saved record of a session kept outside the model from the harness that decides what reaches the model.
Those are practical engineering precedents, not replications of the RLM study. They point in the same direction: teams are already spending design effort on the layer between the model and the work.
As baseline models improve, that layer will matter more. Many systems will have access to capable models. The differentiator will be whether the surrounding harness turns that capability into focused work, useful state, trustworthy evidence, and verified outcomes. A system that repeatedly gives a brilliant model a confused, overloaded job can waste more capability than a modest model working inside a clear, disciplined environment.
Start with one existing workflow and ask five questions:
- What does the coordinating model need to decide now, and what raw material can remain external?
- Can the work be divided into narrow subproblems with clear inputs and checks?
- Which intermediate results should become short records with links to the source evidence rather than prose buried in the conversation?
- Where can ordinary software search, group, compare, or verify before another model call?
- What evidence must return to the coordinating model before it edits, escalates, or declares success?
Do not add ceremony to simple work. A short, well-bounded task may need nothing more than a capable model, a few tools, and a test. Do not expect a harness to manufacture a capability the underlying model does not have either.
But when the work is long, tool-rich, and full of state, the model is no longer the whole architecture. The model still supplies essential capability. The harness increasingly decides whether that capability becomes useful, reliable work.
Sources
- Alex L. Zhang and Omar Khattab. *Language model harnesses are compositional generalizers* (2026)
- Alex L. Zhang, Tim Kraska, and Omar Khattab. *Recursive Language Models* (arXiv:2512.24601)
- OpenAI. *Harness engineering: leveraging Codex in an agent-first world* (2026)
- OpenAI. *Unrolling the Codex agent loop* (2026)
- Anthropic Applied AI. *Effective context engineering for AI agents* (2025)
- Anthropic. *Scaling Managed Agents: Decoupling the brain from the hands* (2026)