The Cost of Being Wrong

There is a meeting that happens in the eighth or ninth month of every serious agentic program. Somebody from finance brings a chart. The chart shows inference spend, and the line goes up. The engineering lead explains that token prices have actually fallen twice since the program started, which is true and which makes the chart worse, not better, because it means the volume grew faster than the price fell. Somebody proposes a cheaper model for the high-volume path. Everyone agrees. The meeting ends.

Six weeks later, spend is down eleven percent and something else has quietly moved. Support tickets mentioning the assistant are up. Two analysts have started re-running the agent's numbers by hand before forwarding them, which they do not log anywhere. A regional director has stopped using it entirely and has told three peers why. None of that appears on any chart, because there is no invoice for it. The organisation optimised the number it could see and paid for it with a number it could not.

This is the structural blind spot in almost every AI budget I have seen. Compute is metered, itemised, and delivered monthly by a vendor with a strong interest in you looking at it. Error is unmetered, distributed across departments, and paid in time, rework, and trust. The first number is easy and small. The second is hard and large. Guess which one governs the decisions.

Start with a single wrong answer and follow it, because the abstraction only becomes useful once it has a number attached. An analytics agent reports a churn figure that is wrong by four points. It is not wildly wrong — wildly wrong answers are cheap, because somebody catches them immediately. It is plausibly wrong, which is the expensive kind.

The figure goes into a deck. The deck goes into a planning meeting where four people spend ninety minutes discussing a retention problem that is smaller than they believe. A budget line gets provisionally moved. Two days later an analyst rebuilds the number by hand for an unrelated reason and notices the gap. Now there is a correction email, a second meeting to unwind the first, and a slightly damaged relationship between the analytics team and the business unit that was told something untrue with a straight face.

Price that. Six person-hours of meeting time at loaded cost. Three hours of investigation. One reversed decision, which may be cheap or may be a quarter of misallocated spend. And one unit of trust, which is the expensive item and the one nobody puts in the model, because trust is not consumed linearly. It is consumed in a step function: people use the system, then one day they do not, and the recovery cost is far higher than the prevention cost would have been.

The token cost of producing that answer was a fraction of a cent. The organisational cost was four figures, possibly five. Any budgeting model that treats the first number as the cost of the answer is not a budgeting model, it is an accounting convenience. Chapter 18 works through the hidden cost structure of agentic systems in detail, and this asymmetry is the largest item in it.

Here is the part that makes cost optimisation genuinely counterintuitive in agentic systems. In classical software, a cheaper implementation produces the same output more efficiently. In agentic systems, a cheaper implementation frequently produces a different output, and the difference is paid for by somebody downstream who is not in your cost centre.

Consider two configurations of the same workflow. Configuration A uses a strong model, retrieves eight well-ranked passages through a reranker, and grounds its answer with citations. It costs four cents per answer and is correct ninety-six percent of the time. Configuration B uses a cheap model, retrieves twenty unranked passages because retrieval quality was the thing nobody tuned, and skips citations because they were slowing the response down. It costs half a cent per answer and is correct eighty-two percent of the time.

Configuration B looks like an eighty-seven percent cost reduction. Run ten thousand answers through each. Configuration A produces four hundred wrong answers. Configuration B produces one thousand eight hundred. That is fourteen hundred additional wrong answers, and if a wrong answer costs the organisation even fifty dollars in review, rework, and correction — a conservative figure in any environment where a human reads the output — then configuration B has spent seventy thousand dollars to save three hundred and fifty.

You will not see that trade in the vendor dashboard. You will see it in headcount that grows to absorb verification work, in cycle times that stretch, and eventually in a program that gets quietly descoped because it never delivered. Chapter 21 treats quality, speed, and cost as a single joint decision for exactly this reason: optimising any one of the three in isolation moves the other two, usually in the direction you were not measuring.

Most organisations set spend policy at the wrong altitude. A cap per team, or a mandated model for everything, or a blanket instruction to reduce inference cost by a third. Each of those treats all work as equivalent, and in agentic systems the variance between tasks is enormous.

Draft a first version of an internal announcement: the cost of being wrong is close to zero, because a human is going to edit it anyway and a clumsy sentence has no downstream consequence. Classify a support ticket into one of nine categories: the cost of being wrong is a small routing delay. Compute a revenue figure that will appear in a board deck: the cost of being wrong is a governance incident. Approve a refund above a threshold: the cost of being wrong is money leaving the company, irreversibly.

Those four tasks should not share a model, a retrieval depth, a verification policy, or a budget. They differ by orders of magnitude in consequence, and the correct spend per answer differs by orders of magnitude too. Uniform policy across them means you are simultaneously overspending on the drafting path and underspending on the path that touches money. Both errors cost, and the second one costs more.

This is the actual argument in Chapter 19, which is frequently misread as an argument for cheap models. It is not. It is an argument for routing by consequence — cheap where being wrong is survivable, expensive where being wrong is not, and never uniform. Chapter 20 turns that principle into budget-aware design, which is the part that has to exist before finance can be given a number it will believe.

Reliability engineering solved a version of this problem two decades ago and the vocabulary transfers cleanly. Instead of an uptime target of one hundred percent, which is unaffordable, site reliability practice sets an error budget: a stated, deliberate allowance for failure, per service, sized to what the business can absorb. When the budget is spent, work stops and reliability work starts. It converts an argument about culture into an argument about arithmetic.

Agentic systems need the same instrument. For each workflow, state the tolerable error rate explicitly, before deployment, in writing, with a business owner's name on it. Drafting can tolerate five to ten percent. Summarisation, two to five. Analytics that reaches a decision-maker, half a percent to two. Anything that moves money or makes an irreversible commitment, zero material error, which in practice means mandatory human approval rather than a heroic model choice.

The moment those numbers exist, three things change. Model selection becomes a derivation instead of a debate, because the required accuracy sets the floor on capability. Retrieval investment becomes justifiable, because a tenth of a point of accuracy has a stated value. And the verification layer stops being overhead, because the cost of the guardrail can be compared directly against the cost of the errors it prevents.

The discipline that makes this real is evaluation. An error budget without a measurement harness is a wish. You need a labelled set drawn from real questions, run on a cadence, scored per workflow, with the results visible to the people who own the budget. Chapter 32 covers the readiness assessment this sits inside, and Chapter 30 covers the observability that makes an error attributable to a cause rather than to bad luck.

When teams finally instrument agentic spend properly, the distribution is almost never what they expected. The headline answer — the tokens in the response the user reads — is usually a minority of the bill. The majority sits in four places, and all four are context problems wearing a cost costume.

Retries. An agent that fails and retries pays twice, and a poorly grounded agent retries often. Silent retry loops are the single most common surprise in a first cost audit, and they are invisible in the user experience because the user only sees the attempt that worked.

Replayed history. In a multi-turn workflow, the conversation is resent on every turn. A twenty-turn session with an uncompacted history does not cost twenty units, it costs something closer to the sum of an arithmetic series. This is why compaction is a cost lever before it is a quality lever, and why Chapter 36 treats the token budget as an engineering artefact rather than a limit you hope not to hit.

Oversized retrieval. Twenty passages retrieved where five would do costs four times as much on input tokens and reduces accuracy, because the additional fifteen passages are noise competing for attention. This is the rare case where the cheaper option is also the better one, and teams still do not take it, because nobody tuned retrieval. Chapter 35 is the mechanics of getting this right.

Uniform reasoning depth. Applying deep multi-step reasoning to a task that needed a lookup is pure waste, and it is the default in most agent frameworks because depth is configured globally rather than per branch.

Notice what those four have in common. Not one of them is fixed by negotiating a better rate with a vendor. Every one of them is fixed by knowing what the model needs to see and giving it precisely that — which is to say, every one of them is a context engineering problem that shows up as a cost problem.

Cost per token is a vendor metric. It tells you about the market, not about your system, and it falls whether or not you do anything well. Cost per call is slightly better and still misleading, because it rewards a system that gives a fast wrong answer over one that takes two attempts to be right.

The number that survives contact with reality is cost per resolved task, fully loaded. Total spend across every call, retry, and tool invocation required to finish the job, divided by the number of jobs actually finished to the standard the business accepts. Fully loaded means including the human minutes spent verifying, correcting, or redoing the output, priced at loaded cost.

That metric behaves correctly under every intervention. Cheapening the model raises human verification time and the number goes up, honestly. Improving retrieval raises input tokens slightly, cuts retries and rework substantially, and the number goes down. Adding a guardrail costs compute and removes an incident class, and the number tells you whether that trade was good. It is the only cost metric I know of that cannot be gamed by shifting work onto somebody who does not hold the budget.

Publish it monthly, per workflow, next to the accuracy figure from your evaluation harness. Two numbers, same page. Every serious conversation about agentic economics can be held with those two numbers, and almost none can be held without them.

One item in the ledger resists pricing, and it deserves its own paragraph because it is the item that kills programs. Trust does not degrade in proportion to error rate. It degrades in steps, and it recovers far more slowly than it falls.

A user who receives one confidently wrong answer does not adjust their confidence by one percent. They begin verifying, which erases the productivity gain that justified the system. A user who receives a second one stops using it, and — this is the part that compounds — tells colleagues, who never form the habit at all. Adoption dies before the accuracy improvements ship, and the improvements then have nobody left to serve.

The practical consequence is that early accuracy is worth more than late accuracy, by a wide margin, and that citations and visible provenance are not a nice-to-have feature but a trust-preservation mechanism. An answer a user can check is an answer that costs one unit of verification. An answer they cannot check is either taken on faith, which is dangerous, or rebuilt from scratch, which is expensive. Chapter 16 makes the case that trust is designed rather than earned by accident, and the economics here are the strongest argument in its favour.

So when you model the cost of being wrong, weight the first six months heavily. Errors during adoption cost multiples of identical errors made later, because they are paid for in a currency you cannot buy back with compute.

None of this requires new tooling. It requires that somebody write four numbers down and keep them current, per workflow.

First, the error rate, measured against a labelled set of real questions, not against vibes and not against a benchmark somebody published. Second, the unit cost of an error in that workflow, estimated with the business owner rather than by engineering, including review time, rework, and correction. Estimate it badly if you must — an order of magnitude beats a blank. Third, the fully loaded cost per resolved task. Fourth, the stated error budget, agreed in advance, with an owner's name attached.

Multiply the first two and you have the monthly cost of being wrong. Put it beside the compute invoice. In every organisation I have seen do this honestly, the first number is several times the second, and the conversation about AI spend changes character permanently within one meeting. It stops being about whether to use a cheaper model and starts being about which investments in context, retrieval, and verification pay for themselves — which is a question with real answers.

The pitch for cheap agentic AI was always slightly dishonest. Not because the models are expensive, but because the discipline is. What you are buying, when you invest in context, is a lower error rate on the tasks where errors are expensive. That is not overhead sitting on top of the AI budget. On any honest ledger, it is the largest line item in it.