Independent Verifier Agents: Don’t Let AI Grade Its Own Work

🎥 The YouTube version is also available:

Independent Verifier Agents: Don’t Let AI Grade Its Own Work

Books: Practical Multi-Agent Systems: Integrating OpenAI Agents SDK • Claude Agent SDK • AutoGen • LangGraph with Chinoba Decision Runtime Implementation Guide

As AI agents become capable of handling design, implementation, testing, and review, development can appear to become dramatically faster.

Provide the requirements.
The AI writes the code.
The AI runs the tests.
The AI reports, “No issues found.”

However, there is an easy-to-miss problem in this flow.

Should the agent that implemented a change be allowed to make the final judgment about whether that implementation is correct?

In human software development, it is risky for the person who created something to review it alone and then deploy it directly to production. Implementers are easily influenced by their design intent and the assumptions they made. They may see what they expect to see and exclude overlooked problems from the scope of verification.

The same is true for AI agents.

This is where an independent Verifier Agent becomes necessary.

A Verifier Agent is separate from the agent that performs the implementation. It checks evidence, permissions, alignment with specifications, test results, and the scope of changes, then reports the verification outcome.

The goal is not to distrust AI.
It is to separate the role of building from the role of verifying, and to avoid self-grading.

“Tests Passed” Is Not the Same as “Requirements Satisfied”

Even if an Implementation Agent runs its tests and every test succeeds, that does not necessarily mean the requirements have been satisfied.

For example, any of the following may occur:

• The tests themselves may have been weakened to fit the implementation.
• Error cases or insufficient-permission scenarios may not have been tested.
• The impact on existing functionality may not have been checked.
• Tests may have been run only in a development environment that differs from production.
• Operational, audit, and safety requirements may not be covered by code tests.
• The specification may have been updated while the implementation still relies on outdated requirements.

In other words, a successful test run is an important piece of evidence, but it is not acceptance itself.

A Verifier Agent does not simply read test results. It independently asks questions such as:

• Which requirement, ticket, or design-document statement is this change intended to satisfy?
• Is the supporting evidence still the current and valid version?
• Are there gaps in the implementation scope, or unnecessary changes beyond the required scope?
• Do the tests genuinely validate the required behavior?
• Does the change affect permissions, policies, or audit records?
• Which areas remain untested or Unknown?

Only then can the technical fact that “the tests passed” be connected to the judgment that “this change is safe to move forward.”

How Is a Verifier Agent Different from an Implementation Agent?

What matters is not simply giving another agent a different name. Verification independence must be ensured across roles, inputs, authority, and evaluation criteria.

A Verifier Agent does not take the Implementation Agent’s explanation at face value.

It cross-checks the change diff, actual test results, specifications, policies, and existing operational rules. When necessary, it reports: “The evidence supporting this claim is insufficient.”

Verification Is Not Limited to Code

The most serious issues in AI-driven changes are not limited to syntax errors in code.

For example, if an AI implements a customer notification feature, the Verifier Agent needs to check a much broader set of concerns:

• Does the implementation conform to the specification?
• Are the criteria for selecting recipients correct?
• Are opt-out preferences and consent status respected?
• Are required approvals in place before sending?
• Does the template contain confidential information or inappropriate wording?
• Are duplicate-send and resend controls implemented?
• Are audit logs and a Decision Trace retained?
• To what extent does the system retry when a failure occurs?
• Are all required production settings in place?

In this way, a Verifier Agent must validate not only feature-level tests, but also business rules, permissions, operations, and auditability.

In enterprise systems, a change that can be operated safely is more important than code that merely works.

Create Evidence-Based Verification Reports

A Verifier Agent’s output must not be a one-line statement such as, “No issues found.”

At a minimum, it should show what was checked, what could not be checked, and the evidence on which its conclusion is based.

For example, a verification report can include the following:

For example, a Verifier Agent could report:

Decision: Needs revision

Tests for standard point awards and monthly cap checks have passed.
However, no test evidence was found for the acceptance criterion requiring withdrawn and suspended users to be excluded.
In addition, the production environment configuration is not included in the release candidate, so confirmation by the operations team is required before deployment.

This report is not intended to blame the implementer. It is structured evidence that enables people to make informed review and release decisions.

Verification Can Be Separated Even When Using the Same Model

When people hear “independent Verifier Agent,” they may assume that the Verifier Agent must use a different AI model from the Implementation Agent.

Using different models, prompts, or retrieval paths can certainly reduce the risk of repeating the same mistakes.

However, what matters more is separating the verification role from implementation.

Even when using the same model, organizations can at least separate the following:

• Separate implementation conversation history from verification conversation history.
• Do not make the Implementation Agent’s self-explanation the only input to verification.
• Access change diffs and test logs directly.
• Retrieve specifications, policies, and acceptance criteria through separate paths.
• Do not grant modification authority to the Verifier Agent.
• Treat Hold and Unknown as formal outcomes, not only Pass.
• Require final human approval for high-risk changes.

These controls avoid a structure in which an agent judges the assumptions it created as correct.

Do Not Turn the Verifier Agent into an All-Powerful Approver

Even when a Verifier Agent exists, not every change should be approved automatically.

Human final approval should remain in place for permission changes, personal-data handling, external customer communications, billing, contracts, and critical production settings.

A Verifier Agent’s decision does not replace human judgment.

It organizes the evidence and identifies verification gaps before people make their decisions.

In addition, information that the Verifier Agent cannot verify must not be treated as approved. If logs are missing, required documents are inaccessible, or the test environment is unknown, the outcome should be explicitly recorded as Unknown or Hold.

Avoiding the assumption that “it is probably fine even though we could not verify it” is what supports trustworthy verification.

Conclusion: AI Quality Cannot Be Guaranteed by AI Self-Evaluation Alone

As AI agents take on implementation work, not only code-generation capability but also the verification mechanism itself becomes essential.

Allowing an Implementation Agent to handle design, implementation, testing, and final judgment may appear fast. But it also creates a risky structure in which the same assumptions, blind spots, and evaluation criteria remain unchallenged.

That is why the agent that builds must be separated from the agent that verifies.

• The Implementation Agent fulfills requirements.
• The Verifier Agent checks requirements, evidence, permissions, and test artifacts.
• Humans make the final decision for material changes.

This separation moves AI adoption beyond simple automation toward a development and operations process that is explainable and continuously improvable.

Do not let AI grade its own work.

This is not about distrusting AI.
It is a fundamental design principle for enabling organizations to use AI-generated outcomes responsibly.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance