Improve your agent

Improve this agent looks for a better version of your agent’s own instructions. It changes only the files you choose, tries each version on your scenario cases in a sandbox, and proposes the best one with its evidence. Nothing changes in your code until you put the change into the session’s draft.

It uses the Propose–Probe–Compose method of Harness² (Google Research, Apache 2.0).

Before you start

On the Evaluations page of a session you need:

• an approved runner (how one case runs);
• at least one active case that is not held out: the run learns from these, the training cases;
• at least one held-out case you wrote: these decide whether a change is proposed.

Starting a run

Open Improve this agent and choose:

• The files it may change. Up to 8 files of your agent’s prompts, agent configuration and skill text: Markdown, text, YAML, JSON, TOML and template files, at most 40,000 characters each and 120,000 together. Nothing else in the repository changes. Code changes go through the normal review in a session instead. These are never offered for a run: files that may hold secrets; billing, sign-in, licence and security policies; CI, build, dependency and release files; tests, evaluation cases and the files your cases’ runner uses; and links (a symlink or a submodule, or a path through one). Your cases, their checks and the held-out set live in WeHarness and cannot be changed by a run. Adding a file later needs a new run.
• Candidates: 3 by default, or 6.
• Time limit: 10 to 40 minutes for the training part (30 by default); the final check on your held-out cases has its own 15 minutes.

Before you start, the page shows the run’s total cap and what it covers: the proposer’s model calls, your agent’s model calls in the trials, the judges your cases ask for, the training sandbox, and the final held-out check. The cap is reserved when the run starts. The run is never charged more than the cap, what it does not use is released, and the candidates and the time limit can stop it sooner. Only a signed-in person can start a run, in the web app.

What a run does

1. Your agent as it is runs every training case in a fresh sandbox.
2. Candidates. Harness² proposes changes from what it saw: some on how the agent works (steps, tool use, output format), some on what it knows (rules, required fields). Each candidate runs the training cases. Then it composes candidates into one.
3. Held-out cases. At most two candidates that beat your agent on the training cases, without losing a case your agent passed or failing a critical check, run your held-out cases once. They run in a second, fresh sandbox. The optimizer never sees those cases: not their input, not their checks, not their results.
4. The result. A change is proposed only when it is no worse than your agent on every held-out case and passes at least as many of them.

Every case is judged by code, the same way as an evaluation run. Model calls go only through WeHarness’s model proxy, with limits on calls and tokens; the sandbox gets no WeHarness key.

Reading the result

The result card shows, for your agent and for the proposed candidate, how many training and held-out cases passed. Each count is out of the cases assigned: a case that failed, could not be decided (evidence missing) or did not run is counted, never left out. The card also shows the diff, the reasons Harness² gave for each change, every candidate, and the credits used.

When no change is proposed, the card says why: no candidate beat your agent, the best ones did worse on held-out cases, or the held-out cases could not be decided.

Applying a change

Put it into the draft writes the proposed files into the session’s draft. Push it from Changes as usual; the push is approved there. If the files changed in the session since the run started, applying is refused: run it again on the current files. Not now declines it.

Coding tools connected over MCP can read the latest result with agent_optimization_get. They see held-out cases only as counts, and they cannot apply a change.