Half of enterprise AI teams re-check agent work before it ships. The verification burden is an architecture problem, not a model problem — here is the budget model and the routing policy that removes it.
Last Updated: September 25, 2026
Half of enterprise AI teams now spend meaningful staff hours re-checking agent output before it ships, and nearly nine in ten re-verify the context their agents read. That is not a model-quality problem you can prompt your way out of; it is an operating cost with three specific sources: context nobody owns, tool outputs nobody can trace, and blanket review applied to steps that do not need it. Price it per reviewed run, then architect it down by making outputs verifiable and routing review by action risk. In regulated work, budget for gates that never go away.
The tax shows up on a payroll line, not a model card
A Harris Poll survey run for Collibra in August 2026 put the first hard labour number on agent verification. Among 306 US data, privacy and AI decision-makers at director level or above, 51% reported spending significant staff hours manually reviewing and correcting autonomous agent outputs before they go live, and 87% said their teams regularly re-verify that the context their agents rely on is still accurate and current. At organisations above $100 million in revenue the manual-review figure rises to 64%.
Two caveats before this goes in a board deck: the survey was commissioned by a governance vendor that shipped products against these findings a week later, and the credible interval is roughly plus or minus 6.4 points. Treat the percentages as directional. The direction matches every agent build that survives contact with a real process: by month three the model is rarely the bottleneck. The review queue is.
Every enterprise scaling AI today is paying a hallucination tax — a hidden cost of manual oversight, rework, and risk.
— Felix Van de Maele, CEO, Collibra, PR Newswire
Where the review hours actually accrue
Almost none of the review burden comes from the model inventing facts out of thin air. It comes from three structural gaps, and only one lives inside the model.
1. Context with no owner and no timestamp
An agent's working context is usually table definitions, policy PDFs, wiki pages and a vector index built on a Tuesday six months ago. None of it carries an owner, an as-of date or a change signal. A reviewer who cannot tell whether the inputs were current re-verifies the inputs, every run. That is the 87% number: a staleness problem masquerading as a hallucination problem, and a stronger model only writes a more confident paragraph on top of the stale source.
2. Tool outputs you cannot trace back
An agent calls a tool, gets back a blob of text or JSON, and asserts a number. Nothing in that assertion tells the reviewer which query produced it, against which snapshot, under whose permissions. The Model Context Protocol and most vendor tool APIs return unstructured content with no provenance envelope, so verification cost collapses into re-derivation cost: the reviewer reopens the source system and redoes the work. When verification costs 70% of the manual task, automation ROI is mostly theatre.
3. Blanket review applied to every step
Teams over-correct because agent reliability is genuinely lumpy. The τ-bench authors introduced pass^k precisely to capture this: a leading function-calling agent succeeded on under half of tasks and scored below 25% on pass^8 in the retail domain, meaning the same task run eight times rarely comes out right eight times. A demo that works is not evidence of a process that works. The rational response to that variance looks like reviewing everything, but it is the single most expensive way to buy safety, because it spends the same reviewer minute on a reversible draft email and an irreversible ledger posting.
There is a model-level reason the human keeps getting drafted, too. OpenAI researchers argued in Why Language Models Hallucinate that training and evaluation reward confident guessing over admitting uncertainty, so abstention stays undertrained. Your agent almost never says "I could not verify this," so someone has to be the abstention mechanism — by default, a person with a queue.
Bolting on a second model as the reviewer
The obvious fix is an LLM judge that grades the first agent's output. It usually fails for a boring reason: the judge sees the same context the generator saw. If the context was stale, incomplete or misattributed, the judge inherits the error and stamps it approved. You have added latency and token spend and moved nothing.
A verification budget you can put in a spreadsheet
Stop arguing about hallucination rates and compute cost per reviewed run. The formula that survives contact with finance is simple:
Cost per run = inference and orchestration + (review minutes × loaded rate) + (escape rate × cost per escaped error) + (rework rate × rework minutes × loaded rate)
The table below is a model, not a measurement from any engagement: 2,000 runs a month, a manual baseline of 40 minutes per run, a loaded reviewer cost of $60 an hour, and roughly $0.45 of tokens and orchestration per agent run. Replace every number with your own; the shape is what matters.
| Review policy | Avg review min/run | Cost per run | Monthly (2,000 runs) | What it assumes |
|---|---|---|---|---|
| Manual baseline, no agent | 40.0 | $40.00 | $80,000 | Nothing automated |
| Agent + blanket review of unverifiable output | 28.0 | $28.45 | $56,900 | Reviewer re-derives the answer from source systems |
| Agent + evidence-linked review | 7.0 | $7.45 | $14,900 | Every claim carries a source link, a diff and a passed check |
| Risk-routed review (18% full review, 5% audit sample) | 1.5 | $1.91 | $3,820 | Escape rate held flat — usually false |
| Risk-routed, escape cost priced in | 1.5 | $6.31 | $12,620 | 1.1% escape rate at $400 per escaped error |
Read the last two rows together; they are the whole argument. Risk routing looks like a 95% saving until you price the errors that now reach production unreviewed. At a 1.1% escape rate and $400 an error, it lands roughly where disciplined evidence-linked review already was. Routing pays only when the auto-released class is genuinely low-severity and you have measured the escape rate rather than assumed it.
The highest-leverage variable is not the routing percentage. It is 28 minutes versus 7. That gap is a function of whether the output is verifiable at a glance — an architecture decision made months before the reviewer opens the queue.
Confidence routing: deciding which steps get human eyes
Route on the properties of the action, not on the model's self-reported confidence. Token-level probabilities and a chirpy "I am 95% confident" are not calibrated to your business risk, and treating them as a gate is how teams end up auto-approving the one irreversible step. Three axes actually predict whether a step needs eyes:
Reversibility. Can this be undone in one action, by one person, within the detection window? Drafting is reversible. Posting to the ledger, sending to a regulator, or emailing a customer is not.
Blast radius. One record or ten thousand? Batch operations deserve a gate even when each write is individually trivial.
Verifiability. Can a deterministic check confirm correctness without a human? If a total must tie to a source sum, that is an assertion, not a review task. In the finance and audit-shaped workflows we build, somewhere between half and three quarters of what teams call "review" turns out to be assertions a machine can run — reconciliation, schema conformity, date-range sanity, permission scope, duplicate detection.
How one run gets classified
Every claim the agent makes carries the tool call, source identifier, snapshot time and the owner of that source.
Recompute, reconcile, validate schema and permissions. Failures never reach a human queue; they go back to the agent with the failed assertion attached.
Score reversibility, blast radius and residual unverifiable content. This is a lookup table you maintain, not a model output.
Auto-release, targeted review of only the unverified spans, or a mandatory gate with a named approver.
Record reviewer edits, escapes found downstream and time in queue. Without this loop your thresholds are guesses and stay guesses.
Step one is the part most teams skip. An evidence envelope per claim is cheap to produce and is what collapses 28 review minutes into 7.
{
"claim": "Q3 intercompany balance = 1,482,930.44",
"source": "erp.gl_balances",
"query_hash": "a91f...",
"as_of": "2026-09-24T02:15:00Z",
"source_owner": "controller.emea",
"checks": [{"name": "ties_to_sum", "status": "pass"},
{"name": "fx_rate_date_match", "status": "pass"}],
"unverified_spans": [],
"route": "auto_release"
}Four places a context layer deletes review entirely
Review is not reduced by trusting the model more. It is reduced by removing the reason a human was looking. Four properties do almost all of the work, and you can implement them in whatever stack you already run — see our automation builds.
Ownership. Every source an agent can read has a named human owner and a documented scope. When a reviewer can see that the policy document came from the compliance owner of record, they stop re-verifying the policy and start reviewing the judgement.
Freshness. Every retrieved item carries an as-of timestamp and a staleness threshold. Past threshold, the agent refuses rather than answers. This converts a silent wrong answer into a loud, cheap failure, which is the trade you want.
Lineage. Claim to tool call to query to source row. Without it, targeted review is impossible, because the reviewer cannot isolate which 5% of the output is unverified and must read all of it.
Write-back proof. The most under-built of the four. When an agent writes to a system of record, capture a dry-run diff before and a read-back confirmation after, with the record identifiers. Most "did the agent do it right" review is actually "did the agent do it at all" anxiety, and a read-back receipt answers that without a person.
The vendor market converged on this in a single week of September 2026, which is the clearest signal that the review burden has become the buying criterion.
Airrived launched Agentic Observability, tracing enterprise data through its Context Lake to agent reasoning, action and outcome, exposing each agent's creator, owner, permissions and whether human-in-the-loop approval is required before it acts.
Cisco shipped Splunk Agent Observability with a Tokenomics capability that attributes token spend across agents and coding tools such as Claude Code, Codex and Cursor, and applies runtime guardrails that block inaccurate or unsafe actions.
Collibra published The 2026 Hallucination Tax Report, naming manual oversight as the hidden cost of scaling agents.
Buying one of these does not delete review. Observability tells you what happened; it does not decide what a human should look at. The routing policy is yours to write and it is workflow-specific. What these products change is the cost of building lineage and write-back proof yourself.
When review is permanent — and should be designed as a gate
Some review never goes away, and pretending otherwise is how programmes lose credibility with risk and audit functions. If a human signature is the control, the signature is the product. A statutory audit sign-off, a credit adverse-action decision, a clinical note entering a patient record, a payroll run — the point of the human is accountability, not error detection, and no amount of lineage removes it. The Collibra data reflects this: 84% of respondents say they have clearly defined executive accountability when agents produce flawed or harmful outputs, and 90% are actively preparing for evolving AI regulation.
Design those gates deliberately. A well-built gate is one screen, pre-populated with the agent's rationale, the evidence envelope and a structured diff, batched so the approver handles forty in a sitting rather than forty interruptions. Measure dwell time and approval-without-edit rate: if approvers never edit, the gate is a rubber stamp and you have the risk without the control.
And there are workflows where the honest answer is do not automate this yet. Three tests I apply before starting a build: is the correct answer contested between competent humans, does the underlying data change during the review window, and are errors discovered months later rather than days? The third is decisive. If your feedback loop is a year long, you cannot measure escape rate, so you cannot price routing, so the only defensible policy is full review — which means the economics do not work and you should automate the preparation steps instead of the decision. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027 on cost, unclear value and inadequate risk controls, and misplaced automation of contested judgements is a reliable way to join that cohort.
The build sequence that actually lowers the bill
Order matters more than tool choice here. Doing these out of sequence is the most common reason a verification programme stalls.
Week 1–2: instrument before you optimise. Log review minutes per run, reviewer edits by step, and escapes found downstream. Almost nobody has this data on day one, and you cannot budget a cost you have never measured.
Week 3–4: convert review into assertions. Take the reviewer's actual checklist and ask which lines are deterministic. Implement those as post-conditions that run on every step. This is the cheapest win available and it typically removes the majority of queue time.
Week 5–6: attach evidence envelopes. Source, snapshot time, owner, check results, unverified spans. Render them in the review UI so the reviewer reads only the unverified spans.
Week 7–8: classify actions and route. Build the reversibility and blast-radius table with the process owner, not the engineering team. Start with a conservative routing policy and widen it as escape-rate data accumulates.
Ongoing: re-price monthly. Model choice affects token cost and step-level accuracy but rarely moves review minutes on its own — our model coverage notes track where that trade sits. Review minutes move when verifiability improves.
If a review queue has eaten the savings your pilot promised, the diagnosis is usually architectural, not model-related. That is what our AI integration and implementation practice exists to unpick — start with one workflow and honest numbers, and tell us what it is.
Frequently Asked Questions
What is the hallucination tax?
It is the recurring human cost of checking, correcting and re-verifying what AI agents produce, plus the rework and risk that follow when checks miss something. Collibra popularised the term in its 2026 report, where 51% of surveyed data and AI decision-makers said they spend significant staff hours reviewing agent outputs before release. Practically, it is a line item measured in reviewer minutes per run, not a model benchmark.
What percentage of agent steps genuinely need human review?
There is no universal number, and anyone quoting one is selling something. The useful method is to classify each step by reversibility, blast radius and verifiability. Steps that are reversible, narrow and checkable by assertion need no human. In practice, most of what teams call review turns out to be deterministic checks a machine can run, leaving a much smaller set of genuine judgement calls and mandatory sign-offs.
Will a better model reduce our verification cost?
Only at the margin. Stronger models raise per-step accuracy, but review minutes are driven by whether a human can confirm an answer quickly, which depends on lineage and evidence rather than model quality. A stronger model reading a stale source produces a more persuasive wrong answer. Upgrade the model for capability; upgrade the context layer to cut review time.
Can an LLM judge replace the human reviewer?
Not when it reads the same context as the generator, because it inherits the same errors and approves them confidently. Judges earn their keep only when given independent evidence, such as a fresh query against the system of record, and only for judgements that cannot be expressed as a deterministic assertion. Run assertions first; they are cheaper, faster and auditable.
How do I calculate cost per reviewed run?
Add inference and orchestration cost, review minutes multiplied by the loaded reviewer rate, escape rate multiplied by the cost of an escaped error, and rework. Compare that against the fully loaded manual baseline for the same unit of work. Track it monthly. The number that usually surprises teams is escape cost, which quietly cancels most of the savings claimed by risk-routing policies.
When should we keep permanent human review in place?
Whenever the human signature is itself the control: statutory sign-offs, credit decisions, clinical records, payroll releases. Design those as deliberate gates with batched queues, pre-populated rationale and structured diffs, then measure dwell time and edit rate. Permanent review is a compliance cost, not a failure of the system, and treating it as failure leads teams to automate exactly the step they should not.
Why do so many agent programmes stall between pilot and production?
Because pilots are scored on capability and production is scored on total cost including oversight. In the Collibra survey, 76% hit critical roadblocks moving agents into production and 72% traced underperformance to weak or unaligned data foundations. A pilot with a human silently checking everything looks successful; the same workflow at a thousand runs a month exposes the review queue as the real constraint.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime