What does an AI agent mistake cost? A pricing model for the wrong answer

Teams budget carefully for tokens and almost never for error. The model call behind an agent decision costs a fraction of a cent. The decision itself can cost a refund, a clawback, a file reopened by an auditor, or a consent order. If you price only the first number, every agent looks cheap. This post gives you a way to price the second one before you scale, and shows why the moment you catch an error decides most of what it costs.

The token bill is the small one

The cost of an AI agent error is everything a wrong decision triggers after it is made: the money that leaves, the people who redo the work, the regulatory and legal exposure, and the trust the program loses. For most agents in regulated or money-moving work, that total is larger than the entire inference bill for the year. It is also the number nobody puts in the business case.

Tokens show up on an invoice every month. Errors show up later, spread across other budgets: a write-off in finance, overtime in operations, a remediation project in compliance. Nobody adds them up, so the agent looks cheaper than it is.

The survey numbers show where that leads. Camunda's 2026 survey of 1,150 senior IT and business leaders found that only 11% of agentic AI use cases reached production in the past year. Gartner projects that more than 40% of agentic AI projects will be canceled by the end of 2027. And 65% of enterprises surveyed by EMA for Cequence Security in September 2026 said an AI agent had already acted outside its intended scope. Many of those projects stall because the people who sign off can't put a ceiling on what a mistake would cost.

Four kinds of cost

Every wrong agent decision lands in one or more of four buckets. They behave differently, so it is worth pricing them separately.

Direct loss is the bucket people price first, because it is the easiest to see. It is rarely the biggest. Rework is usually larger: once an agent has made an error nobody can locate, the only safe response is to check everything it did. Regulatory cost arrives in steps, when an examination or audit turns a pattern of small errors into a finding. Trust is the bucket that ends programs, because one visible incident changes how risk treats every agent that comes after it.

A worked example: one rule, 10,000 decisions

Take a lending agent. The credit policy caps loan-to-value at 80%. An older lending procedure, never retired, says 85%. An application arrives at 83%, and the agent approves it, because in that run the procedure carried more weight than the policy.

On its own, that decision may cost nothing. Most 83% loans perform. But the loan is priced and reserved as if it were inside policy. If it defaults, the loss is larger than the credit committee agreed to take. And when an examiner samples the file, it is an exception nobody approved, which is a finding whether or not the loan performs.

Now scale it. Say the agent handles 10,000 applications a year and gets 1% of the threshold decisions wrong. That is 100 loans outside policy. None of them was decided by a person. None of them is flagged. To find them, someone has to re-check every file the agent touched, because nothing in the logs tells you which runs leaned on the wrong document. The direct loss may still be small. The rework is the cost of reviewing 10,000 files. The regulatory exposure is a pattern finding. The trust cost is that the next agent in lending waits a year.

The same arithmetic works in other industries with different nouns.

Claims. An agent settles low-value property claims. The claims manual lets it pay up to $5,000 without an adjuster. The product wording excludes a type of water damage that the manual's summary table doesn't mention. The agent pays a few dozen excluded claims a month, each one small, each one correct by the manual it read. Nobody notices until a reinsurer's audit asks why the loss ratio on that product moved. Now the cost is the leakage, a review of every claim the agent paid, and a conversation with the reinsurer about controls.

Payables. An agent matches invoices to purchase orders and releases payment. The finance policy allows a 2% price variance; the approval matrix, updated last year, says 1% for one supplier category. The agent applies 2% everywhere. Each overpayment is small, and none of them comes back without a recovery claim that someone has to file and chase. Over a few thousand invoices a month, the leak is real money, and the recovery effort is a second cost on top of it.

All three examples are illustrative.

Why "95% accurate" is the wrong number

Most agent business cases report an accuracy figure. It answers a question the people who sign off don't ask. The useful number is the expected cost of error over a year, and you can write it down:

Expected cost of error = volume × error rate × cost per error × (1 + detection delay factor)

Volume and error rate are the familiar part. Cost per error is the sum of the four buckets above for one wrong decision. The detection delay factor is the part most teams leave out, and it is usually the biggest lever. It captures how much the cost grows between the moment a decision is made and the moment someone notices. A wrong decision caught before it executes costs a blocked action. The same decision caught a quarter later costs the action, the rework of everything around it, and whatever happened in between.

Two things follow. First, an accuracy improvement from 95% to 97% matters less than it sounds if errors are still found by audit. Second, a modest error rate with immediate detection can be cheaper than a very low error rate with no detection at all, because the expensive part of an error is how long it stays wrong.

What history has already priced

There aren't yet many public, fully priced incidents involving AI agents, because few agents have been trusted with consequential actions for long. But automated and semi-automated actions without a gate have been priced many times. None of the cases below involved an AI agent. They show what the four buckets look like when they arrive together.

A trading router with no gate in front of it. On August 1, 2012, a defect in Knight Capital's order router sent more than 4 million orders into the market in about 45 minutes while trying to fill 212 customer orders. The firm lost more than $460 million, according to the SEC, which later fined it $12 million. The detail that matters for agents: the system had sent 97 automated emails flagging the problem before the market opened, and nobody acted on them. The firm had monitoring. It had no control that stopped orders above its limits before they reached the market.

A payment that went out at more than a hundred times its size. In August 2020, Citibank meant to send about $7.8 million in interest on a Revlon loan and sent roughly $900 million. Lenders holding about $504 million refused to return it, a federal judge initially let them keep it, and the case ran until an appeal and a settlement in 2022. In October 2020 the Federal Reserve and the OCC fined Citi $400 million and ordered it to fix its risk management and internal controls. The error took seconds. The cost took two years.

A chatbot that made up a policy. In February 2024, a Canadian tribunal ordered Air Canada to honor a bereavement refund its website chatbot had promised against the airline's actual policy. The award was a few hundred dollars. The airline argued the chatbot was responsible for its own statements; the tribunal held the company responsible for everything on its website.

In each case the large numbers came from scale, from money that couldn't be recalled, and from what regulators and courts concluded about the controls afterward.

The hidden costs: checking everything, and paying to retry

Two costs rarely appear in incident reports, and they are the ones teams feel every week.

The first is blanket review. When nobody can say which agent decisions might be wrong, people check all of them. An operations leader at a bank told us that at least half of the requests their team received had to be kicked back for missing information or the wrong steps, before any agent was involved. Put an agent on that process without settling the rules, and the review queue doesn't shrink. It moves. The agent produces work faster, and the same people re-check it, now without knowing what the agent assumed.

The second is retry cost. A common pattern is to have one model check another: generate, evaluate, regenerate until the evaluator is satisfied. It catches errors, and it multiplies the inference bill by the number of loops. An AI and automation lead at a bank told us loops like these burn through tokens. The error cost goes down a little. The running cost goes up a lot.

Both costs share a cause. The rule lives inside the model's interpretation, so the only way to control the outcome is to inspect it afterward, again and again.

Where the cost gets decided: before or after

The cheapest error is the one that never executes. Every other control works on errors that already happened.

Plot the cost of one wrong decision against the time it takes to catch it. At the left edge, a preventive control checks the action against the rule in force and blocks it or sends it to a person: the cost is a short delay. A few minutes later, a monitoring alert catches it: the action may already have executed, so now there is a reversal. A day later, a reconciliation catches it: there is a reversal plus everything built on top of the wrong decision. A quarter later, an audit catches a pattern: now you are re-checking every decision of that type and explaining the gap to someone outside the company.

Monitoring moves the catch point from the right of the curve toward the middle. Only a control in front of the action moves it to the left edge. We wrote about that distinction in detail in A dashboard is not a gate.

What teams say when they see the number

"Our error rate is very low." It may be. The question is whether you know which decisions are the errors. A low error rate you can't locate still forces a full review when one is found, and one public mistake moves the whole program into the trust bucket. Price the detection delay, not just the rate.

"We have people reviewing the agent's work." Then you are paying for the agent and for the people, and the review is detective: it happens after the decision. That can be the right design for low-stakes work. For decisions that move money, change a record, or commit the company to a customer, the review is worth more in front of the action than behind it, with the rule in front of the reviewer.

"Insurance covers it." Insurance covers some direct loss and some liability, after a deductible and a claim. It doesn't cover rework, it doesn't cover a stalled program, and an insurer asked to pay for a pattern of errors will ask what controls were in place. A control in front of the action also makes the risk easier to insure.

What to do on Monday: a one-page error-cost worksheet

You can price the cost of error for one agent in an afternoon with the process owner and someone from finance or risk. No tools needed.

1. List the decisions the agent makes that change something. Approve, pay, price, send, update. Ignore what it reads or summarizes.
2. For each, write the rule a person follows today and where it lives. If you find two versions, write both down. That gap is your most likely error.
3. Estimate the four costs for one wrong decision. Direct loss, rework hours times a loaded rate, regulatory or legal exposure (ask compliance for a range, not a point), and a trust note: what would happen to the program if this error became visible.
4. Write down when you would catch it today. Before it executes, same day, month-end, or at audit. Be honest. Most answers are "at audit".
5. Multiply it out. Volume per year, times your best estimate of the error rate, times the cost per error, adjusted for when you catch it. Put the result next to the inference cost. If the first number is ten times the second, the business case is about errors, not tokens.
6. Mark the decisions where moving the catch point to "before" changes the answer. Those are the decisions that need a rule checked in front of the agent.

Where Factify fits

Factify is built for the left edge of that curve, so read this section knowing we're not neutral.

In the terms of the worksheet: Seal removes the most likely errors before any agent runs, Enforce moves the catch point to before execution, and Prove shrinks the rework when something does need to be found.

Frequently asked questions