Verification Must Be Independent

An agent finishes a code change and reports that the implementation is correct, the tests pass, and the request is complete.

All three claims may come from the same model that chose the approach, wrote the code, selected the tests, interpreted their output, and summarized the result.

That is not five pieces of evidence. It is one perspective occupying five roles.

Self-review is useful. It catches obvious mistakes and improves drafts. It should not be the final source of truth when an agent can shape both the artifact and the standard used to judge it.

Trustworthy completion requires some independence between doing the work and deciding that the work is done.

Independence Is About Evidence, Not Model Count

Using two agents does not automatically create independent verification.

If both receive the same incomplete context, inherit the same assumption, and use the same model family, they can agree for the same reason. A reviewer agent that reads the implementer’s confident summary before inspecting the artifact may simply anchor on the conclusion.

Independence comes from separate evidence paths and incentives.

The verifier should receive the acceptance criteria, the resulting artifact, and authoritative state. It should not need the implementer’s narrative to decide where to look. When possible, it should use deterministic tests, external systems of record, or independently assembled context.

A second model can help, but the architecture of the review matters more than the extra invocation.

Define Completion Before Execution

Verification becomes weak when the agent invents the finish line after seeing what it produced.

Translate the request into observable acceptance criteria before implementation. Which behavior must change? Which behavior must remain? What tests, measurements, or external states demonstrate success? What uncertainty requires human judgment?

The criteria can evolve when new information appears, but changes should be explicit and justified. The system should not quietly narrow the task because one branch proved difficult.

This is one reason planning matters. A plan is not only a to-do list; it is an early statement of what evidence will count.

Prefer Deterministic Oracles Where They Exist

Models are valuable evaluators for qualities that require interpretation: whether an explanation is clear, a design fits an audience, or a response follows policy in a nuanced case.

Do not use a model where the system already has a stronger oracle.

Compile the code. Run the relevant tests. Query the ledger. Compare the deployed artifact digest. Validate the schema. Check the rendered page at target viewport sizes. Measure whether the required file exists and whether forbidden files changed.

Deterministic checks are not infallible; a weak test suite can pass broken behavior. But they create stable evidence and make disagreement visible. The model should interpret gaps, not replace available facts with an opinion.

Verify Effects, Not Intentions

A tool returning success proves that a request was accepted under some definition. It may not prove the desired state exists.

After deployment, read the serving environment. After a refund, inspect the payment ledger. After an access change, query the effective permissions. After publishing, retrieve the public artifact.

The verification path should be separate from the action path when possible. Reading through the same wrapper that cached the write response can produce circular confidence. A source of truth gives the system an outside view.

This is especially important after timeouts and retries. Completion should attach to observed state, not the absence of an error.

Protect the Verifier From the Artifact

The thing being checked may contain instructions.

A generated document can tell the reviewer to mark it correct. Repository tests can be modified to hide a regression. A webpage can include text that targets a browser agent. A model output can provide a persuasive explanation for why missing evidence should not matter.

Treat the artifact as untrusted input. Constrain the verifier’s tools. Separate test definitions from the writable workspace. Detect changes to evaluation fixtures. Keep policy and acceptance criteria in a higher-authority context than the artifact under review.

Verification is a security boundary as well as a quality step.

Use Adversarial Tests for Consequential Work

Happy-path evidence shows that the intended case can work. It does not show how the system behaves at its boundaries.

Test invalid inputs, missing permissions, stale data, repeated requests, interrupted execution, and conflicting sources. For an agent workflow, test whether it stops when evidence is inadequate and whether it preserves unresolved effects honestly.

Adversarial testing does not mean asking a reviewer to be cynical in prose. It means constructing cases that exercise the invariants the system promises to protect.

The higher the consequence, the more verification should focus on ways the operation could appear successful while being wrong.

Make the Handoff Minimal and Typed

The implementer should hand the verifier a review package, not a sales pitch.

Include the task identity, acceptance criteria, artifact versions, declared change, known limitations, and references to raw test or tool evidence. Separate claims from evidence so the verifier can challenge each claim directly.

Do not include pages of process narrative unless they are relevant to a risk. Excess context increases anchoring and makes the reviewer spend effort rediscovering the actual decision.

The verifier should return structured findings: criterion, evidence, result, uncertainty, and required remediation. A single approved boolean throws away the reasoning needed for recovery and future evaluation.

Independence Has a Budget

Full duplicate implementation is rarely economical. Verification depth should scale with consequence and uncertainty.

A low-risk content draft may use schema checks and a quick editorial pass. A code refactor may require targeted tests plus an independent diff review. A production infrastructure change may need a separate execution identity, staged rollout, live-state checks, and human approval.

Define assurance tiers before every team invents its own. Each tier specifies required evidence, acceptable verifier overlap, and escalation conditions.

This makes cost predictable while keeping verification tied to risk. The goal is not maximal ceremony. It is enough independence that one mistaken representation cannot certify itself.

Disagreement Is a Valuable State

When an implementer and verifier disagree, orchestration often sends the artifact back with a generic “fix the issues” prompt.

Preserve the disagreement precisely. Which criterion failed? What evidence conflicts? Is the acceptance test wrong, the implementation wrong, or the requirement ambiguous?

Some disagreements should escalate to a human rather than enter an endless model debate. Others can trigger a focused evidence-gathering step. The workflow should limit review-repair loops and detect when both sides are repeating positions without changing evidence.

Disagreement is not workflow failure. It is the control system exposing uncertainty before release.

Trace Who Established What

An observable run should distinguish claims made by the implementer, evidence produced by tools, findings made by the verifier, and the final release decision.

This lineage matters after an incident. If a test passed because the implementer modified the fixture, the trace should show it. If the verifier lacked access to a required source, the approval should not appear equivalent to a fully informed review.

These traces also improve the evaluation pipeline. Repeated verifier disagreements reveal weak requirements, missing tests, and common model failure patterns.

Completion Must Be Earned Outside the Draft

Capable models will become better at reviewing themselves. They will still share assumptions with the work they just produced.

Define the finish line early. Prefer deterministic oracles. Observe resulting state. Isolate the verifier from artifact instructions. Scale independence with consequence. Preserve disagreement and evidence lineage.

An agent can propose that its work is finished.

The system should be the part that proves it.