A meta-harness optimizes the harness. Your repo is the part that compounds.

A meta-harness is the layer above an agent harness. It searches harness code, or routes a task across several harnesses, instead of running one agent itself. Both senses of the term are in use, and the research behind the first measures how far harness code can move a benchmark. That research makes the case for treating the harness as a component rather than a foundation.

Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. The harness is one component inside it, and the definitions it runs are the part a company keeps.

Two things called a meta-harness

The research sense comes from a 2026 paper by Yoonho Lee and colleagues: Meta-Harness is "an outer-loop system that searches over harness code for LLM applications" (arxiv.org/abs/2603.28052). The harness in that sentence is the code that decides what to store, retrieve and present to the model. The meta-harness is the loop that writes candidate harnesses, runs them, reads the traces and tries again.

The product sense is looser and newer. A vendor explainer calls a meta harness "an orchestration layer that manages multiple AI agents as a unified system" (MindStudio). In its telling, a dispatcher picks which coding agent handles a task and passes context between them. The worked example is OmniAgent, which the page calls "an open-source meta harness designed specifically for AI coding agents", wrapping Claude Code, Codex CLI and others behind one interface. MindStudio publishes the explainer and sells its own platform: a visual workflow builder it describes as "essentially a no-code meta harness builder".

Both senses are real, and both sit above a single harness. The research loop emits harness code. The orchestration layer calls harnesses that already exist. Neither one replaces the harness underneath, which is why the interesting question is what that harness is allowed to touch.

What the Stanford experiment measured

The paper's headline result is on TerminalBench-2, 89 Dockerized tasks with five trials each. With Claude Opus 4.6 underneath, the discovered harness passed 76.4% of tasks, against Terminus-KIRA's 74.7%. The same table, headed Pass %, puts Claude Code at 58.0, Terminus 2 at 62.9 and Meta-Harness at 76.4. On Claude Haiku 4.5 the search reached 37.6% against Goose's 35.5%, with Claude Code at 27.5 (project page).

The method is the part worth copying. Most optimizers compress the history of past attempts into a score, a summary or a short window of recent candidates. Meta-Harness gives the proposer a filesystem holding the full source, scores and execution traces of every prior candidate. A coding agent reads it with grep and cat. The project page puts the difference at "up to 10M tokens of diagnostic context per step, vs. at most 26K for all prior methods we surveyed".

That budget buys diagnosis. The proposer can trace a failure to the harness decision that caused it instead of guessing from a number. The abstract reports 7.7 points over a state-of-the-art context management system while using 4x fewer context tokens. A single discovered harness added 4.7 points on average across five held-out models on 200 IMO-level problems (arxiv).

On this bench, harness code is a searchable variable. Searching it moved the same model 18.4 points above Claude Code, and 1.1 points above Capy, the strongest baseline in the table at 75.3. The lead over the best hand-built harness is thin. That is the point: the frontier is crowded, and no harness holds it for long.

What a discovered harness does not carry

A discovered harness is fitted to the tasks it was scored on. The TerminalBench-2 search ran on 89 tasks in code translation, distributed ML setup, systems programming, bioinformatics and cryptanalysis. The math search evolved a retrieval program on 250 problems, then tested it on 200 held-out ones. The harness that wins is the one that best fits that family, and the next benchmark produces a different winner.

So the gain is real and it does not accumulate inside a company. A harness is a file, and the next paper, vendor or internal experiment replaces it. What accumulates is the set of definitions the harness runs. That means which agent exists, what each one may use, what the company remembers, and who approved the last change. Those belong to the company, and they are the part that has to survive a swap.

The question for a buyer is what remains in the repo when the harness underneath changes. A benchmark table does not answer it.

Where the boundary sits in Kortix

Every session runs an open-source agent harness. The harness is one adapter behind a contract, and the boundary README states the rule: "harness.ts is the only module that imports a concrete adapter", and "An unknown id fails the boot" (README). Selection happens once, at boot: "There is no per-request switching: one box, one harness, for the life of the box."

A swap is a migration, and the README describes one that has already been made in the code. Since 2026-10-30 kortixd has no OpenCode adapter, and open-code/ is deleted. A box that OpenCode booted before that date can still wake: it maps to pi, boots pi, and with session-log restore on it restores the log into pi and records the switch in harness.history.

What does not move is the manifest. The starter template opens with the line that says what the file is for:

# {{projectName}}: the Kortix project manifest. Agents, what each may use,
# triggers and sandboxes live here, committed beside your files.

# The agent a session or trigger runs when it names none. My Kortix, the agent
# you talk to, is built in: it routes each task to the right agent below.
default_agent: worker

agents:
  worker:

    mode: primary
    permission: allow
    prompt_file: agents/worker.md
    tools: all
    skills: all
    connectors: all
    secrets: all
    kortix_permissions: all
    workspace: { project_repository: true }

The default_agent line does the routing the orchestration products sell. It does it in a file a colleague can read in a diff. Each agent's block is where its tools, skills, connectors and secrets grants sit. Change the harness and the grants still describe what the company decided.

The rest of the boundary lives in the same repo.

• One isolated sandbox per session. Each session has its own isolated machine and branch.
• Per-resource permissions for people and agents. Roles, groups, and an audit trail.
• Session work reaches main through a change request. Merge is default-deny for agents.

Questions to put to anyone selling a meta-harness

• Where does the harness live: your repo, the vendor's, or the model lab's?
• What can you read before a run: the prompt, the tool list, the grants?
• If you change the harness tomorrow, which files stay?
• Who approves a change to what an agent may touch?
• What record does the run leave, and who can read it?

Two related reads: the harness as a component of an open-source CompanyOS and Kortix vs OpenHands on the record a coding harness leaves.

If you want the definitions to outlive the harness, start at Kortix.