MetaHarness: scaffolding a branded agent harness from any repo

The problem MetaHarness targets: every repo gets its own agent, not another framework

The README states the position directly: "It is not another agent framework. It is a factory for agent frameworks." The unit of work is a repository. You point the tool at a GitHub URL or start from a blank slate, and it produces a harness scoped to that repo: a CLI, a coding agent, a local MCP server, memory scoped to the project, skills generated from the actual file layout, a governance policy, and release verification. The output is described as an npm-publishable zip carrying your name, your branding, and your own npx entry point. The audience is therefore not someone looking for a general agent runtime. It is someone who already has a repo and wants an agent that knows that repo's layout, and who wants to hand that agent to other people under their own package name. The README frames the model as replaceable and the harness as the product, which is a coherent stance: if the model is a commodity, the repo-specific wiring is where the value sits.

What the scaffold actually produces, and how the pieces fit together

From the README, the generated artifact contains a custom harness for the target repo, recommended agents, skills, slash commands and MCP tools, a scoped memory namespace with a governance policy, and witness-signed provenance with release gates. Skills are derived from the repository's file layout rather than declared by hand, which is the mechanism that makes the output repo-aware. The MCP server is local, so the tools the agent exposes are served from the machine rather than a remote endpoint. The host layer is separate from the harness layer: the same generated output drops into Claude Code, OpenAI Codex, pi.dev, Hermes, OpenClaw, RVM or Prime Agent, and the README says you can pick one or all. Prime Agent is described as the tenth host and takes a different path from the others: it has no MCP, so the host package emits tools as project-scoped, Python-backed skills under .prime/agent/skills/ plus an install runbook. That is a concrete architectural difference, not a label. On the evolution side, every scaffold ships with Darwin Mode wired in; npm run evolve mutates the harness config, tests each change in a sandbox, and keeps only changes that measurably improve. The README states the model stays frozen while the harness evolves, and that the loop runs with no network and no API key, behind a safety gate.

Getting it running: npx metaharness, score, and the flags that change the output

The primary entry point is npx metaharness, and the README also points to a browser Studio at ruvnet.github.io/metaharness/ where the same generation is described as happening in under 60 seconds with nothing leaving the machine. Before scaffolding, npx metaharness score <repo> reads a repository, never runs it, and prints a report card covering harness fit, likelihood of building, tool safety and rough cost per run. That is a read-only step, which matters if you are evaluating a third-party repo you do not want to execute. For host selection the README gives --host prime-agent as the flag for the tenth host. For the evolution loop, --no-darwin skips Darwin Mode at scaffold time. Prime Agent also has an opt-in --sessions flag that writes a crash-recoverable JSONL session log, and the README states the Rust and TypeScript (wasm) replays of that log produce identical state hashes. The library form is @ruvnet/agent-harness-generator if you want to call the generator from code rather than the CLI. One detail worth noting: the README's description of the ARC-AGI-3 ChatGPT package says ChatGPT is the reasoning host and that neither package uses the OpenAI API or an OPENAI_API_KEY, so no key is required for that path.

The limitation that matters most: fail-closed behaviour and unproven claims

The Prime Agent host is the clearest documented failure mode. The README states that Prime Agent cannot enforce a deny-list itself, so when a non-empty deny-list is configured the host ships a prominent SANDBOX-REQUIRED.md rather than silently dropping the posture. That is the right call, but it means your governance configuration is not enforced by the host; it becomes a document you have to act on. If you assumed the generated policy travels with the harness into every host, Prime Agent is the counterexample. The second limitation is claim discipline, which the project applies to itself. The ARC-AGI-3 packages are described as private and experimental, and the README says no ARC performance claim is made until an official closed scorecard satisfies the frozen controlled-ablation gate in ADR-254. A single-game smoke result is reported as favoring AVO 3.2676 to 0.3968, and the same sentence says that non-competition result is not claim-eligible. Similarly, @metaharness/avo has a deterministic 205-action RVF interruption proof, while the stronger AVO-class claim is described as blocked on a preregistered 100-task unseen SWE-bench gate in ADR-251. Read that as a warning about scope: the packages that sound most capable are the ones the project refuses to stand behind yet. @metaharness/field-memory is also described as experimental, single-process by default, with a RuVector adapter that fails closed unless a corrected flat-index wrapper is used.

Where MetaHarness is the wrong tool, and what to use instead

If you want a single agent runtime with a stable API and you do not care about per-repo branding, MetaHarness adds a generation step you will not use. The README's own framing makes this explicit: it is a factory, so the product of the factory is what you operate. A project that just wants an MCP server for one repo can write that server directly and skip the scaffold, the governance policy and the release gates. The more useful comparison is against @metaharness/darwin, which is not a competitor but a component with a different approach to the same problem of improving agent behaviour. Darwin Mode mutates the harness config and keeps only changes that pass a sandbox test behind a safety gate; the README describes simple work staying on Darwin's fast path while @metaharness/avo takes over difficult engineering work with governed variation, budgets, promotion, quarantine and rollback. The difference is the search space: Darwin edits configuration, AVO inspects, edits, executes real tools, evaluates, repairs or reverts, branches, consults structured RVF memory and commits. If your problem is that your agent's configuration is badly tuned, Darwin is the relevant piece. If your problem is that the agent cannot complete a multi-step engineering task, configuration mutation will not reach it, and the AVO path is the one the project itself says is not yet claim-eligible.

Maintenance cost, release cadence and the MIT licence

The release list shows v0.4.4 as a catch-up release titled "Darwin evolution, the Flywheel, security hardening, and 115 PRs since v0.1.3", published 2026-08-10, with v0.1.3 on 2026-06-14. That is 115 pull requests in roughly two months, which tells you the surface is moving quickly and that pinning a version matters more than usual for a tool that generates code you then publish. The earlier v0.1.3 release is described as shipping .claude-plugin/plugin.json in every scaffold, so generated output has already changed shape once. There is also a published-smoke GitHub Actions workflow, which the README surfaces as a badge, indicating that the npm publish path is tested. The repository is MIT licensed, which permits commercial use and modification; the README does not describe any separate licence for generated output, so if you plan to publish a harness under your own name, confirm the generated files carry the terms you expect rather than assuming. This is not legal advice. The practical maintenance cost is the host matrix: ten hosts, one of which has no MCP and needs a different skill format, means a change in any host can require a change in a host package.

Who should adopt it, and what to check before you scaffold

The fit is narrow and specific. You maintain a repository that other people will run agents against, you want that agent to carry your package name and your npx command, and you are comfortable reading ADRs to know which packages are production and which are experimental. The README's own labelling gives you the map: ARC-AGI-3 and AVO are private and experimental with claims blocked on named gates, field-memory is experimental, and Darwin Mode is wired in by default but can be skipped with --no-darwin. Start with npx metaharness score <repo> to see the fit, build likelihood, tool safety and cost per run before generating anything, then scaffold and inspect what you got. The thing to verify first is the host you will actually use, because behaviour differs: Prime Agent cannot enforce a deny-list and emits SANDBOX-REQUIRED.md instead, and it has no MCP at all, so its tools are Python-backed skills under .prime/agent/skills/. If your governance posture depends on the host enforcing it, that host will not, and the README says so.

Editorial conclusion

Adopt MetaHarness if you want a repo-scoped agent with its own npx entry point, MCP server and memory namespace, and you are willing to read the ADRs before trusting any of the experimental packages. Do not adopt it if you need a stable, versioned API surface today: the project is at v0.4.4 with 115 PRs landing between v0.1.3 and v0.4.4, and several packages are described as private and experimental. Verify three things first: which host you will target, because Prime Agent ships a SANDBOX-REQUIRED.md instead of enforcing a deny-list; whether your scaffold should include Darwin Mode at all, since --no-darwin exists and the evolution loop mutates config; and what the generated zip actually contains, because the README describes the output as an npm-publishable artifact with your name on it.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ruvnet/metaharness on GitHub