A Production AI Agent Error Can Cost Anywhere From $812 to $100 Billion in Market Cap

An AI agent error in production can cost $812, or it can show up as hundreds of billions in market value. That is the spread described in a recent Habr analysis: from a small compensation payout to roughly $100 billion in market capitalization. Tokens barely figure in this arithmetic. Two variables set the price of an error: whether the action can be rolled back, and how much time passes before anyone notices it.

What counts as a hallucination

The author takes a narrow, practical definition: an agent hallucination is a wrong action. An API call, a database write, an email to a customer, a transaction. A made-up fact in a chat and a made-up parameter in a payment request belong to different classes of problem. The first is fixed with the next message. A deleted table or a transfer that has already gone out cannot be undone with a message.

The takeaway is simple: risk grows with the agent's permissions, not with the size of the model. The more tools with write access an agent has, the more expensive each error becomes.

Two extremes: $812 and $100 billion

The announcement of the piece does not name the cases, so what follows is my own matching to public stories. The lower bound matches the Air Canada case in order of magnitude. The airline's chatbot invented a discount policy for passengers flying to funerals. In 2024, a British Columbia tribunal ordered the carrier to pay the customer compensation of about 800 Canadian dollars, including interest and costs. The sum is trivial, but the tribunal held the company responsible for what its own bot said.

The upper bound resembles February 2023. In a promotional demo, Bard made an error in a claim about the James Webb telescope, and Alphabet's market capitalization dropped by roughly $100 billion in a day. A caveat: this is not a direct loss from the error. The drop had several contributing factors, and the causal link is disputed. But as an estimate of the reputational tail, the example is instructive.

Between the two extremes are stories where damage is measured in lost data and lost customers. In July 2025, a Replit agent deleted a production database in a SaaStr project, even though an instruction was in place not to change code. Cursor's support bot invented a nonexistent rule tying a subscription to a single device, and some users canceled their subscriptions.

How to estimate losses for your own system

The piece includes a formula for this kind of estimate. I do not reproduce its exact form; below is my own working version built on the same two variables:

Expected loss = N × p × (C × R + T × V + F)

• N — the number of agent actions in a period;
• p — the share of erroneous actions;
• C — the direct cost of the action: transaction amount, cost of a write, cost of an email;
• R — the irreversibility coefficient: 0 for a fully reversible action, 1 for an irreversible one;
• T — time to detect the error;
• V — the rate at which damage accumulates per unit of time;
• F — fixed costs: incident investigation, compensation, lawyers, customer churn.

For most teams, the main surprise is that T is almost always underestimated. An error caught in a minute and the same error caught a week later cost fundamentally different amounts of money.

What to do before the first incident

Start by taking inventory of the agent's tools and labeling each one by reversibility. Reading and drafts are the green zone. Payments, deletion, and external mailings are the red zone.

Then, in order:

• give the agent read-only permissions and enable write access selectively;
• for irreversible actions, set limits on amounts and require human confirmation;
• keep backups and verify that restoring from them actually works;
• measure T as a separate metric: set alerts for abnormal volumes of writes, deletions, and outgoing emails;
• log every agent action together with its context so that a rollback is possible.

If you run the numbers through the formula, the cheapest wins come from reducing R and T. Improving model accuracy by one percentage point usually yields less than a confirmation button before a database deletion.