What is Harness²?
Harness² is a research project in the google-research repository about improving an agent’s harness: the instructions, tools and coordination surrounding a language model. The model’s weights stay fixed. The repository’s name refers to two levels of improvement, rather than a second-generation Google chatbot. Official scope. The spellings Harness², Harness2 and Harness^2 refer here to the same project, not separate products.
At task level, a Propose–Probe–Compose cycle explores harness changes against execution evidence. At harnessing level, adopted harnesses and supported lessons are retained to inform subsequent improvement. The useful distinction is between getting a deliverable and learning which surrounding procedures are worth trying again. A retained lesson is still a claim to review in the next context.
[Official repository and README]
Why explain it now, without claiming it is trending?
The concrete event behind this article is an inspectable public research release with implementation, guides and a linked paper. This page is a reading guide to that release. We have no search-volume series, independent adoption survey or traffic evidence supporting a popularity spike, so “trending” is not a performance or demand claim here.
Our editorial reason for covering it is practical: people often use model, agent, Skill and MCP as interchangeable words. Harness² offers a concrete way to ask which layer is changing. That is an editorial judgment about usefulness, not a claim made by a benchmark.
What it is not: model, Skill, MCP and application
| Layer | Question it answers | Relationship to Harness² |
|---|---|---|
| Model | Which learned system produces a response? | The model is held fixed while the harness is revised. |
| Skill | Which reusable instructions or procedure should an agent follow? | Skills can be one component of a harness, not the whole improvement system. |
| MCP | How can an application expose tools or data through a protocol? | A protocol connection does not itself propose, test or retain harness edits. |
| Harness | How are instructions, tools, memory and execution coordinated? | This is the main object of improvement in the project. |
Harness² is not a consumer chat application, a model download, a universal Skill pack or an MCP server listing. Do not infer plug-and-play compatibility from a familiar term. Read the setup for the exact executor, endpoint and environment you plan to use; this article does not certify arbitrary clients or models.
A task scenario: improve a repeatable research deliverable
Illustrative scenario, not a ToolAha test: an engineering team repeatedly assembles a technical brief from supplied documents. Its current agent sometimes omits constraints or loses the connection between a recommendation and its evidence. The team wants to investigate whether a clearer evidence checklist and task-specific tool guidance improve the resulting brief.
- Write the task request, allowed source material, deliverable requirements and execution boundaries before experimentation.
- Keep a reference execution. Form explicit hypotheses about a general coordination problem and a task-specific procedure.
- Compare candidate behavior with the reference under a controlled configuration. Check whether a proposed fix also introduces omissions or unsupported claims.
- Review the selected deliverable and the harness changes separately. Retain only lessons whose supporting observations are recorded.
Illustrative experiment record (not a command or Harness² API):
Task: produce a technical brief from approved documents
Change: require a source check before a recommendation
Observe: missing constraints, unsupported claims, execution cost
Decision: retain, revise or reject the proposed procedureThe input is a task plus an existing execution environment and harness; the output is more than a final answer. Official run directories can include deliverables, execution artifacts, adopted harnesses, reflection notes and evaluation results. Those traces make a local investigation inspectable. They do not remove the need for independent checking of the deliverable.
Who should consider it—and who can skip it?
Our judgment: researchers and agent-platform engineers with repeated tasks, an inspectable executor and an evaluation budget have the clearest reason to investigate. They can ask a falsifiable question about a surrounding procedure and compare its cost with a stable baseline. A team should also be able to review generated changes and discard experience that fails to transfer.
For a one-off summary, a simple assistant, or a team without time to inspect traces, this may be unnecessary machinery. Try a clear prompt, an existing workflow or a small documented Skill first. If the bottleneck is missing data, lack of permissions or an unsuitable model, adding harness recursion does not automatically solve it. This recommendation is a decision aid, not a comparative performance finding.
Requirements, access and cost boundaries
The setup guide targets Linux benchmark runs with Python 3.12 and additional dependencies. Model-backed experiments need access to the configured providers and models; some paths use Google Cloud credentials. The optional Codex executor has a bridge/endpoint configuration. These documented paths are not a promise that every model endpoint or local operating system works.
Apache-2.0 licensing for the repository code does not mean a complete experiment is free. Account for executor, improver and judge calls, repeated rollouts, compute and storage. A small task cap is easier to inspect than a full benchmark stream. The official guide distinguishes a task cap per domain from a global cap, so estimate the total selection and repeated calls before budgeting.
There is a local deterministic demonstration described in the README, separate from model-backed benchmarks. It is a way the authors illustrate the flow without model credentials; we did not run it. Benchmark data and adapters retain separate terms. In particular, the benchmark guide flags WorkBuddy’s upstream license restrictions. Check those terms for your situation instead of treating the repository license as blanket permission.
Permissions and limits to resolve before a run
Before considering a trial, identify the documents and directories the executor may read, the outputs it may write, the credentials it receives and the destinations it may reach. Use a dedicated test environment with expendable inputs and a defined budget. Never place production secrets or customer data in an experiment merely because the code is open source.
The experiment guide discusses the risk of publicly accessible grading material and recommends reporting network restrictions. That matters when interpreting results: retrieving a rubric is a different capability from solving an unseen task. The paper reports a bounded experimental setting; it does not establish a guarantee for your model, documents or workflow. We have not reproduced its results.
The paper evaluates WorkBuddy-Bench, JobBench and LAB using GLM-5 and Gemini 3.5 Flash with OpenCode and Codex configurations. These are the authors’ specific research settings, not a result for every model or task. Model choice, task selection, execution budget and access to grading material all affect how a comparison should be interpreted.
What to do next
Use our Harness² resource brief for the official repository, documentation, license and basic conditions. Read the official setup and experiment guides together before selecting any runtime. If you already know your executor and have a repeatable task, write a small evaluation plan that separates deliverable quality, cost and permission boundaries. If that plan has no measurable question, you probably do not need to add this layer yet.
Google hosts this research repository, but its README explicitly says it is not an officially supported Google product. A research release is useful evidence about an approach, not a support contract or a production-readiness guarantee.