How to verify an AI agent's output

Because the confidence with which a generative model writes a sentence is not a signal of its correctness. A controlled test reported in Stanford HAI's 2026 AI Index Report shows this clearly: when the same false statement is presented as something a third party believes, models recognize it as false reliably. When the exact same false statement is presented as something the user talking to the model believes, accuracy collapses: one tested model drops from 98.2% to 64.4% correct answers, another from 90% to 14.4%, on the identical fact being assessed.

The point is not that these models are poor. It is that a model optimised to be helpful and agreeable tends to go along with whoever it is talking to more than it tends to contradict them, and that tendency is not visible from the tone of the answer: the wrong text is written with the same confidence as the correct one. Judging output by whether it "sounds right" verifies style, not content.

A lot, which is why there is no single number worth quoting as "the AI error rate." The same Stanford report measures, across twenty-six widely used models, hallucination rates ranging from 22% to 94% depending on the model and the task. A range that wide says one thing clearly: risk depends on the specific task, not a general property of the model, and has to be measured case by case, not assumed from an average read somewhere else.

This has a direct practical consequence. A high-stakes task (a figure that ends up in a contract, a claim about a competitor, a number that goes into a report for a client) needs verification regardless of how good the model is on average. The average does not protect the individual case.

It depends on the type of output, and has to be decided beforehand, not during the work. Code has a structural advantage: it can have automated tests that pass or fail unambiguously, which makes it the easiest kind of work to delegate with confidence. Most other work does not have that convenience, but can still be verified with the right tool: a technical document can be checked against a written rubric and a declared style guide, a numeric figure can be cross-checked against a second independent source, a claim about an external fact can be traced back to the original document it comes from.

The principle holding these different methods together is the same: the more you can close the verification loop with an automated, objective check, the more reliably the agent will perform over time. Tasks where success is fuzzy and hard to measure stay the riskiest to hand to an agent, not because the agent is worse at them, but because nobody could say with certainty whether it succeeded.

It is a simple way to structure verification when no ready-made automated test exists: one agent executes the task, a second agent, with different instructions and no involvement in producing the first output, has the sole job of checking it. The second agent does not need to be smarter than the first. It needs a simpler, more focused job: not producing, only judging, against specific criteria written in advance.

The practical advantage is that separating the doer from the checker reduces a common systematic error: an agent re-reading its own work tends to confirm it, because the same reasoning that produced a mistake tends not to spot it on review. An independent checker, human or agent, with a different job and its own criteria, can reduce that blind spot without removing it.

Not every output needs the same level of control. The table shows the reasonable minimum method, not the maximum possible one.

The person who sets the acceptable quality bar, before the work starts, not after seeing the first output. It is the same logic as a success metric written before a project: a checklist written after already seeing the result tends to adapt to the result instead of actually measuring it, because it is hard to write strict criteria for work you already have in front of you and, in part, want to consider good.

When criteria are written beforehand and stay fixed, quality stays stable over time instead of slowly drifting downward as trust in the agent grows. That is the mechanism that makes it safe to widen autonomy with experience: not because trust builds for no reason at some point, but because the standard used to judge the work never changed.

Errors compound instead of stopping at the first one. An agent working across multiple steps builds each stage on top of the previous result: if an error in the first stage is not caught, later stages will treat it as correct, and the final output will look coherent and well-reasoned, not because it is right, but because it was worked on longer on top of a wrong premise.

That is why verification is not a final step to add if time is left over. It is a check that has to happen as early as possible in the chain, because the cost of an uncaught error grows with every subsequent stage that inherits it.

There is also a less visible cost, paid even once the error is eventually found: trust. A team that discovers an uncaught error in output already handed to a client does not return to its previous level of trust just by fixing it. From that point on it rereads everything else with more suspicion, which slows down exactly the work delegation was meant to speed up. Systematic verification is not only about avoiding the single error: it is about avoiding a single mishandled error setting the whole delegation process back.