When an AI agent's output looks polished and confident, your review process may already be failing. This article explores why fluent, well-structured agent output is harder to supervise than broken output. You'll leave with two concrete instruments for measuring whether your review step works.
A note on the openings in this series: each is a composite, assembled from patterns that recur across organizations rather than an account of a single company. Every statistic is real, sourced, and dated.
The quality review was scheduled for an hour and finished early.
The team had pulled forty items the agent had drafted over the previous week and put them in front of the reviewers who normally sign that work off. Thirty-eight came back approved. The two rejections were easy calls — a malformed reference number, a missing required field. Both wrong in ways you could see from across the room.
The operations lead was satisfied. Ninety-five percent acceptance, in production, on real work. She said so in the readout. The team's data scientist asked to run one more pass. He took twelve of the thirty-eight approved items, stripped the formatting, and gave them to a different set of reviewers with no indication that an agent had produced them or that anyone had already signed off.
Those reviewers found substantive errors in four.
Four items had been read, approved, and released by qualified people who were paying attention. Nothing about them looked wrong. That was the problem.
Figure 1. What the review step actually caught. The two rejections were the items no reviewer could have missed. The four failures surfaced only under a technique nobody had run before — and would otherwise have been counted, permanently, inside a 95% acceptance rate.
Article 01 closed on a question every organization answers automatically for its human staff and struggles to answer for its agents: who is this, what are they allowed to do, and who is answerable for them? Onboarding answers it on day one.
This article is about the day after — when the agent is working, the owner is named, and the review step exists on paper.
An agent's malformed output is cheap. It fails a schema check, breaks a template, returns a null, and gets caught by the first person or process that touches it. The cost is a few minutes of rework. An agent's fluent, well-structured, confidently-worded output that happens to be wrong is expensive. It passes formatting checks. It reads like the work of a competent colleague. It gives a reviewer nothing to catch on.
Three things make that harder to fix than "tell reviewers to look more carefully." Two are properties of the models. The third is a property of the humans.
In September 2025, OpenAI published research — with a co-author from Georgia Tech — arguing that hallucination is not primarily a bug awaiting a patch but a behavior that standard evaluation actively rewards. Benchmarks score accuracy. A model that says "I don't know" scores the same as a model that answers wrong: zero. A model that guesses sometimes gets lucky. Across enough training and evaluation, guessing dominates abstaining.
The paper's comparison makes the trade legible. On the factual-question benchmark it reports, GPT-5-thinking-mini declines to answer 52% of the time, producing 22% accuracy against a 26% error rate. OpenAI's o4-mini declines 1% of the time and produces 24% accuracy — marginally better — against a 75% error rate.
Two percentage points of accuracy, purchased with nearly three times the wrong answers.
Two caveats before that number gets carried too far. It measures short-form factual question answering, not enterprise agent workflows, and the transfer from one to the other is an inference rather than a finding. And it compares two specific models at one point in time; the models will change.
What is unlikely to change is the incentive that produced it, because it is structural. As long as leaderboards score correctness and treat abstention as failure, calibration is something a lab has to choose to pay for against its own benchmark position. The practical consequence for a supervisor is the same either way: the model that hedges hands its reviewer a usable signal, and the model that scores better hands them nothing — every answer arriving in the same confident register, the wrong ones indistinguishable from the right ones at the surface.
An agent that flags its own uncertainty is doing half your supervision for you. An agent that never does has quietly moved all of it onto a human with no way to know which items deserve the scrutiny.
The second property is that agent reliability degrades with the length and complexity of the task, and it degrades steeply.
Salesforce AI Research built CRMArena-Pro to test agents on realistic enterprise CRM work. Leading models completed roughly 58% of single-turn tasks successfully. On multi-turn tasks — the same underlying work, with a conversation around it — success fell to roughly 35%. Adding conversational turns cost more than twenty points. The same study found agents showed near-zero inherent awareness of confidentiality, and that prompting them into it degraded task performance: safety and capability trading against each other directly.
METR's longer-horizon measurements point the same way. Their work on task length found models succeeding on close to 100% of tasks a human would finish in under four minutes, and under 10% of tasks taking a human more than four hours. Their January 2026 update puts frontier models' 50%-success time horizon in the low hundreds of minutes, with confidence intervals METR itself calls very wide and a caution that the trend is sensitive to task composition. The cliff is the finding. The midpoint is not.
For a supervisor the operational reading is simple. Reliability is high where the task is short and bounded, and falls off somewhere in the middle of the range where most interesting enterprise work lives. A review process calibrated during a two-week pilot of short tasks is calibrated on the easy end of the agent's own curve.
And when agents are chained, the failure surface changes shape rather than merely growing. A Berkeley-led team hand-annotated 150 execution traces across seven multi-agent frameworks and derived fourteen failure modes in three categories — system design issues, inter-agent misalignment, and task verification failures. The middle two have no equivalent in single-agent review. Nobody is watching the handoff.
The third property belongs to the reviewer, and it is the one that makes "look harder" fail.
Automation bias is the documented tendency to over-trust automated output, and it strengthens rather than weakens as the automation gets more reliable. A system that is right most of the time trains its reviewers to expect correctness. Every approval that turns out fine reinforces the habit. The reviewer is not being lazy — they are updating correctly on their own experience. The residual is exactly what that updating makes invisible.
European regulators considered this important enough to legislate. The EU AI Act's Article 14, governing human oversight of high-risk systems, requires that people assigned to oversight be enabled to "remain aware of the possible tendency of automatically relying or over-relying on the output." The obligation sits on the deploying organization to build oversight that survives a reviewer being human — not on the reviewer to be less human.
Faros AI's 2026 telemetry shows the shape of the failure at scale. Across roughly 22,000 developers and 4,000-plus teams, AI-assisted throughput rose — and pull requests merged with no review at all rose 31.3%, median time in code review rose 441.5%, and the ratio of incidents to pull requests rose 242.7%. This is vendor-produced research, but it is observed system telemetry rather than a survey, which makes it unusually hard to wave away. The review step did not disappear. It got longer, more crowded, and easier to wave through — and the incidents followed.
Supervision is not approval. Approval asks whether the output looks right. Supervision asks whether it is right. Those are different questions, they cost different amounts, and only one of them is a control. A reviewer who has never rejected anything is not a reviewer. They are a signature.
Most of what follows from this is measurement rather than process, and two numbers do nearly all the work.
The rejection rate, and specifically a very low one, read as an alarm rather than a result. If your supervising humans reject a negligible share of agent output, there are two explanations: an agent performing better than any published benchmark suggests is plausible, or a review step that has become a formality. Assume the second until you have evidence for the first. This is the cheapest instrument available and almost nobody reads it.
The blind re-review disagreement rate. Take a random sample of already-approved output, strip the approval, and route it cold to a different qualified reviewer. The gap between the two verdicts is your real error rate. Every other measure in this space confirms what the primary review caught; this is the only one that measures what it missed. It is what turned a 95% acceptance rate into a very different conversation in the opening of this article.
The second instrument is not free, and the cost is the reason it is rare. A meaningful sample means paying senior reviewers to re-read work that has already been signed off — pure duplicated effort from a throughput perspective, at exactly the seniority band that is hardest to spare. Run it monthly on one workflow rather than continuously on all of them and treat the result as a calibration exercise with a cadence, not a permanent overhead. A quarterly figure you trust beats a continuous program nobody funds past the first month.
There is a fair objection to all of this: if the agent is genuinely performing well, blind re-review is an expensive way to confirm good news. That is true, and the answer is that you cannot know which case you are in without measuring, and the cost of the measurement is bounded while the cost of being wrong about it is not.
Three habits support the instruments.
Require the agent to surface uncertainty and accept that it will cost you. Marking low-confidence outputs lets you route scarce attention where it pays. It will make the agent look worse on aggregate accuracy, and CRMArena-Pro suggests it may genuinely cost some task performance. A calibrated agent at 70% is more supervisable than an uncalibrated one at 80%.
Set review depth by task length, not output volume. Reliability falls with task horizon. Short bounded single-turn work can be sampled; long multi-step work, especially anything crossing between agents, needs to be read. Most policies scale scrutiny to how much output arrives rather than to how hard the work was.
Give the reviewer the ability, the time, and the standing to reject. Article 14 requires that overseers be able to disregard, override, or reverse an output and to stop the system. That has to exist in the workflow, not the policy. If rejecting means missing a queue target or explaining yourself to a delivery lead, the control is decorative.
Most organizations running agents in production can tell you their acceptance rate, and most are pleased with it.
Far fewer can tell you their blind re-review disagreement rate. Fewer still have measured it once.
The first number describes how the review step behaves. The second describes whether it works. An organization with a 95% acceptance rate and no idea what a second reviewer would find has not measured its agent's quality — it has measured its reviewers' agreement with the agent, and automation bias predicts that number will look good whether or not the agent is any good.
The team in the opening did not have a bad agent. It was performing roughly as the research says to expect. What they changed was not the model. It was what review meant.
Article 03 takes up the next layer: escalation — and why "route it to a human when you're unsure" turns out to be a design decision most organizations have never actually made. If you have run a blind re-review pass, I would be interested in what the gap turned out to be, and whether the result changed the process or just the conversation. Both outcomes are informative.
This blog sheds light on the demands the evolution of IT has placed on organizations and the dynamic job opportunities it has brought IT professionals.
ForgeRock is modernizing Identity Access Management (IAM) to help organizations protect against internal and external threats to their systems. Learn more in this blog post.
Improve Python code with named tuples. Learn how to create clear, efficient data structures and use named tuples effectively.
Ascendient Learning is the coming together of three highly respected brands; Accelebrate, ExitCertified, and Web Age Solutions - renowned for their training expertise - to form one company committed to providing excellence in outcomes-based technical training.
With our winning team, we provide a full suite of customizable training to help organizations and teams upskill, reskill, and meet the growing demand for technical development because we believe that when talent meets drive, individuals rise, and businesses thrive.
