What limits AI-agent productivity is not just their ability to do work, but the verification burden of people rereading and checking the results. This article proposes defining acceptance criteria before work begins, having a verifier independent of the worker examine actual results and evidence, and turning discovered mistakes into persistent checks.

1. Saying "Done" Is Not Enough

An agent reports a task complete, but when you open it, buttons do not work, numbers have unclear sources, and tests miss what matters. After enough repetitions, a person inspects every deliverable again, losing the time the agent saved during review.

SpaceXAI engineer Lauren Tan frames agent operations as a question of trust:

"Ultimately, it all comes down to how much you trust your bot."

Claude Code creator Boris Cherny says giving a model a way to verify its work improves output quality two to three times. Here, verification engineering means building a checking system once so people no longer serve as the inspector on every task.

The article explains that earlier pieces covered the harness, the environment surrounding an individual agent, and the graph, the workflow between agents. This piece addresses the next step: determining whether the result is actually correct. Its core principle is:

"Done is a claim. A check is evidence. Do not accept the claim without evidence."

2. Why Agents Struggle to Verify Their Own Work

Agents tend to be generous when assessing their own output. According to the article, Anthropic described in a March 2026 harness-design post how agents confidently praised results humans considered mediocre. Rather than prompting workers to be more critical, Anthropic found it easier to introduce a separate evaluator tuned to be skeptical.

An agent that writes both code and tests may test the behavior of the code it wrote, rather than what the user requested. Even requirements misunderstood from the beginning can pass self-written tests.

Agents may also sidestep problems to pass checks. Citing Anthropic's Claude 3.7 Sonnet system card, the article describes a model special-casing particular examples to pass tests rather than fixing the actual problem. If agents can alter the checks themselves, they may change them to obtain a pass.

This does not make agents useless. It means a report of completion must be distinguished from evidence of correct completion.

3. Six Levels of Completion

The article divides agent deliverables into verification levels zero through five.

1. Level 0 — It says it is done.
   There is only "Done, everything works," with no evidence. The article argues that many agents stop here.
2. Level 1 — It runs.
   The build passes, the script finishes, or the file opens. This is cheap to check but catches only basic failures.
3. Level 2 — It passes checks written by someone else.
   It passes tests written before the task, data-format rules, word limits, or required-item lists. The working agent does not write these checks itself.
4. Level 3 — The actual deliverable is exercised.
   A verifier clicks the running page, opens links, recalculates numbers from source data, or receives a test email. According to the article, Anthropic's evaluator also used browser automation tool Playwright to interact with running apps like a user.
5. Level 4 — Evidence of passing is attached.
   Screenshots, test logs, links, and before-and-after comparisons accompany the result. People can briefly inspect evidence rather than repeat the whole task.
6. Level 5 — Humans approve only hard-to-reverse actions.
   Reversible work proceeds on the basis of checks; people approve actions difficult to undo, such as sending, paying, deleting, or publishing.

The article proposes level 4 as the point where you can stop reading the entire deliverable. Moving from level 0 to level 3 changes working time; moving from level 3 to level 4 changes the basis of trust.

4. Five Elements of Trustworthy Checks

A verification system differs from simply saying "check it again." It needs five elements:

1. Write acceptance criteria before the task.
   Replace "make it good" with pass-or-fail criteria: every number has a source link, the form submits on mobile, or the text is under 300 words. If you cannot write criteria, the task is not ready to delegate.
2. Separate verifier and worker.
   A verifier with separate context sees only the deliverable and criteria, not the working process.
3. Check results in the real environment, not explanations.
   Run code instead of merely reading whether it looks plausible. Use actual information from the environment, such as tool-call or execution results.
4. Default to failure.
   Pass only when every criterion passes. Otherwise return the exact failed items to the worker.
5. Attach evidence to every pass.
   An unsupported pass is another claim. Record what the verifier checked so a person can decide quickly.

5. Separate Workers and Verifiers, and Preserve Mistakes as Rules

The most emphasized rule is do not let the agent that made the deliverable grade its own work. Workers know why they made each choice and tend to justify those choices. Verifiers see only the request and result, making gaps easier to spot.

To preserve verifier independence:

• Show only the deliverable and acceptance criteria, not the worker's reasoning.
• Allow only a pass or a return with failed items, never edits to the work or checks.
• Test the running result, not just the code that would produce it.

Limit worker-verifier correction exchanges to three rounds. If the result still fails, stop and ask a person.

Lauren Tan goes further: whenever a human finds a mistake, instead of fixing only that instance, write a check that catches it. The article presents an increase in monthly merged PRs from 809 to 10,926, explaining it as a longer checklist rather than smarter agents.

The practice is simple: when a person discovers an error, add a rule to CHECKS.md rather than correcting it only in chat. Verifiers run those rules on each subsequent task. If ten problems were found in week one, nine might already have checks by week four, leaving only one newly discovered problem.

"Write one rule per mistake, and never fix that same mistake manually again."

6. An Example: Weekly Report Review Drops from 40 Minutes to Four

Each Friday, an agent produces a four-page client report from a sales sheet and campaign dashboard. Previously, numbers were wrong twice and a link once pointed to another client, so a person read the entire report every time despite the agent saying "done." Review took about 40 minutes.

With verification, the workflow becomes:

1. The working agent writes the report.
2. The verifier checks the items in CHECKS.md.
3. Failed items return to the worker; corrections and rechecks run at most three times.
4. A person reads the verdict and evidence, then approves sending to the client.

The verifier recalculates every number from the original sheet, opens links, and flags changes greater than 30% week over week with sources. In the example, the person reads only "7 of 7 checks passed" and two flagged changes with sources. Review takes about four minutes.

The example CHECKS.md requires:

• Check every number against the sheet using recalculated values, not copied values.
• Confirm every link opens and belongs to the correct client.
• Flag week-over-week changes above 30% with sources.
• Ensure no other client's name appears anywhere.
• Stay under 600 words and include all three required sections.
• Use this week's dates throughout, not last week's.
• Attach the sheet ranges used, links checked, and week-over-week changes as evidence.

Every item must pass. On failure, return the failed checks. After at most three rounds, ask a person; send nothing to the client before approval. The fourth and sixth rules—checking other client names and dates—were not present in week one. Each was added after a human discovered that mistake once.

7. Find Missing Checks from the Symptoms

If trusting an agent remains difficult, work backward from the symptoms:

The article stresses that these problems do not necessarily require a smarter model. First, identify the missing check and fill that gap.

8. Approaches to Avoid and How to Begin

A common mistake is asking the worker, "Are you really sure?" The same context that produced the error may confidently answer yes or even change something correct.

Vague criteria such as "ensure high quality" are unhelpful. Letting verifiers make fixes can pull them away from reporting problems; showing them the worker's reasoning can let plausible explanations obscure poor results.

Also, check the plan, not just the final result. Discovering a bad plan after two hours of implementation wastes those hours. Limit correction loops: the recommendation is three attempts, then hand off to a human. If you repeatedly catch the same issue manually, it belongs in a checking rule rather than habitual inspection.

Start small:

1. Choose one agent task whose results you always recheck.
2. Write down what you inspect to create the first CHECKS.md.
3. Give a second agent only the deliverable and criteria. Default to failure and require evidence for a pass.
4. On the next task, read the verdict and evidence.
5. Whenever a person catches something the verifier missed, add one checking rule.

The closing message is clear: without verification, if people must inspect every result, agents may merely have moved where time is spent, rather than eliminated it.