How the verifier gate works before any local-model edit is trusted
The deterministic checks Agent Harness runs on every local-model code edit before it's accepted, independent of the model's own confidence.
By Agent Software
The problem with trusting a model's own confidence
Local models used for bounded coding tasks are cheap and fast, which is exactly why Agent Harness relies on them for scoped edits. They're also occasionally wrong in ways that sound confident — a model reporting success doesn't mean the edit actually did what it was supposed to do. Trusting that report directly would mean inheriting every one of those failures silently.
What the verifier gate actually checks
Every edit a local model produces goes through a deterministic verifier before it's accepted, independent of anything the model itself reports:
- Scope — did the change stay within the files and areas it was authorized to touch
- Expected text — does specific expected content actually appear where the task required it
- Tests — do the relevant tests pass after the change
- Policy — does the change comply with the task's configured constraints (allowed paths, blocked commands, and similar rules)
None of these checks ask the model to self-report. They inspect the actual resulting state of the code.
Why determinism matters here
A verifier that itself relies on another model's judgment just moves the reliability problem one layer down instead of solving it. Harness's verifier gate is deterministic on purpose — the same edit produces the same verdict every time, which is what lets the rest of the system treat "verified" as a meaningful, stable signal rather than another probabilistic guess.
This is what makes cheap models usable at all
The economic case for local models in a coding harness only works if the harness can catch their mistakes reliably. A verifier gate that inspects real output — files changed, text present, tests passing, policy respected — is what turns "a fast but occasionally unreliable model" into "a fast model whose unreliable outputs get caught before they land."
What happens when verification fails
A failed verification doesn't get silently retried into oblivion or forced through — it becomes a signal the rest of the harness can act on: retry with more context, escalate to a different model, or surface for human review, depending on how the task is configured. The point of the gate is to make failure visible and actionable, not just less frequent.
