Quick answer
A meta-harness, explained two ways
"Meta-harness" has two recognized senses. In product operations, it runs, compares, and coordinates many agent harnesses through one interface. In research, Stanford's 2026 Meta-Harness is an outer loop that improves one harness by searching over its code and execution records. Both senses are capabilities of the Unified Harness Protocol (UHP), the open, versioned HTTP contract for running agent harnesses through one interface. HarnessRouter has the product-sense properties.
An agent harness turns a model into a system that can finish real work by supplying the execution loop, tools, context, permissions, and environment. UHP standardizes the contract around that system. Once runs share the same contract, a product can treat the harness itself as a swappable, measurable component, and an optimizer can consume consistent execution records from repeated runs.
Meta-harness splits two ways, and either way it is a capability of UHP. One sense operates many harnesses; the other optimizes one; both build on the runs one contract produces and makes comparable.
Why now
Many harnesses create an N × M integration problem
Products can choose among established and emerging agent harnesses, but harnesses expose different lifecycle surfaces and semantics. If M products each integrate N harnesses directly, the ecosystem repeats the same adapters, session logic, streaming paths, file handling, and failure mapping N × M times.
UHP changes that topology. A product integrates one public contract, and a conformant server exposes harnesses through that contract. The result is the foundation for both senses of meta-harness: operations can compare many harnesses without rebuilding the product boundary, and research can work from runs recorded in a consistent shape.
Product sense
Operate many harnesses through one contract
In the product and operational sense, a meta-harness runs, compares, and coordinates harnesses such as Codex, Claude Code, and Hermes through one interface. This is a capability of UHP because the contract gives every run a common boundary.
- A shared lifecycle: UHP defines version negotiation, capability discovery, task lifecycle, streaming events, sessions, files and artifacts, and cancellation across harnesses.
- Session continuity through the common contract. HarnessRouter's hosted implementation performs the operational running and provides sandboxed execution isolated from the product's infrastructure.
- Harness and model as caller-controlled parameters, so a product can change its selected configuration while keeping the same integration.
- Same-task comparison: the caller can send identical work to different harness and model configurations, then score cost, quality, and latency on comparable results.
- One place for streamed events and caller-defined budgets, plus UHP's failure taxonomy and its retry and idempotency semantics.
UHP makes runs comparable; the caller decides how to evaluate them and where to route the next task. The contract does not choose a route or guarantee a business result. Its job is to preserve one interface while the product measures and swaps the harness behind it.
Research sense
Optimize one harness from its execution records
In the research sense, Meta-Harness is Stanford IRIS Lab's name for the outer loop described in its 2026 paper. That system searches over a harness's own code, scores candidate versions, and uses prior execution records to discover a better version of the single harness under study.
This sense is also in UHP's orbit. The optimizer is a consumer of runs, and the comparable runs it can feed on are the ones UHP produces. UHP does not improve the harness itself. The research-sense Meta-Harness performs that improvement by deciding what to change, running candidates, evaluating their records, and continuing the search.
The two senses therefore meet at the run boundary. Product operations use comparable runs to choose among many harnesses. Research uses comparable runs to optimize one. UHP supplies the shared contract both capabilities build on.
Boundaries
Three nearby concepts with different jobs
A meta-harness is not an LLM router. An LLM router chooses where an individual model request runs. The product-sense meta-harness works with complete, multi-step harness runs that include sessions, tools, files, events, and artifacts. UHP makes those runs comparable, and the caller controls any routing policy.
A meta-harness is not an agent framework. A framework helps developers assemble an agent. The product sense operates complete harnesses, while the research sense searches over the code of a harness that already has an evaluable task loop.
A meta-harness is not an SDK for one harness. A single-vendor SDK exposes that harness's native surface. UHP gives products one versioned contract across the harnesses a conformant server exposes.
Economics
What the spread is worth
The value of running harnesses through one contract is measurable with a same-task benchmark. When HarnessRouter ran identical work through eight harness × model configurations, only two sat on the efficiency frontier: every other setup in this test had an alternative that was both cheaper and faster. Neither was the obvious pick in advance. Finding them took running the same task through every configuration behind one contract.
The frontier does not tell you where to sit on it. In this test, moving from its cheapest point (0.47 credits, 2m 33s) to its fastest (40.7 credits, 1m 25s) bought a 1.8x speedup for about 87x the credits. Comparable runs let the caller turn that tradeoff into a routing policy: urgent tasks can use the fast point, while batch work can use the cheap one. UHP supplies the comparison boundary; the caller owns the routing decision and its economics. Full data and methodology are on the benchmark page.
In practice
HarnessRouter implements the product sense
HarnessRouter is the world's first unified interface for agent harnesses.
HarnessRouter initiated UHP and develops it in the open, and its open-source Community Edition is the reference implementation. Its hosted service has the product-sense meta-harness properties: a product sends a task through the UHP contract, selects Codex, Claude Code, or Hermes, and receives a comparable run without changing its integration.
As the hosted implementation, HarnessRouter performs the operational work: it runs the selected harness in an isolated session and streams progress, files, and reviewable artifacts back to the product. UHP defines the contract for those interactions. A research-sense optimizer can consume the resulting runs, but the optimizer, rather than UHP, is responsible for improving a harness.
Live usage across reviewed harnesses is published on the agent harness rankings with disclosed methodology.
FAQ
Meta-harness: common questions
What is a meta-harness in AI?
The term has two recognized senses. In product operations, a meta-harness runs, compares, and coordinates many complete harnesses through one interface. In research, Meta-Harness is an outer loop that improves one harness by searching over its code and execution records. Both are capabilities of UHP because they build on runs produced through one comparable contract.
What is the difference between an agent harness and a meta-harness?
An agent harness turns a model into a working system with an execution loop, tools, context, permissions, and an environment. A product-sense meta-harness operates several such harnesses through UHP, making them measurable and swappable. A research-sense Meta-Harness optimizes the code of one such harness by evaluating repeated runs.
Is a meta-harness the same as an LLM router?
No. An LLM router selects where an individual model request runs. A product-sense meta-harness operates complete multi-step harness runs with sessions, file inputs, streamed events, and artifacts. UHP makes those runs comparable, while the caller decides whether and how to route among them.
Is this the same as the Stanford Meta-Harness paper?
It is one of the term's two senses. Stanford IRIS Lab's 2026 paper names an outer-loop optimizer Meta-Harness: it searches over one harness's code using scores and execution records from candidate runs. The product sense operates many existing harnesses. One optimizes a single harness, the other operates several, and both can build on comparable runs produced through UHP.
Do I need a meta-harness if I only use one coding agent today?
UHP can still keep your product boundary stable when one harness is selected today. The product-sense capability becomes useful when you compare another harness or make the current choice swappable. In HarnessRouter's published same-task benchmark, the tested configurations showed a 475x cost spread on identical work. The research sense is relevant when an optimizer evaluates and improves that one harness from repeated runs.
Operate harnesses through one stable interface
Run Codex, Claude Code, and Hermes through UHP, compare their results, and keep routing under your product's control.
Start building free