The Economics of Reasoning: What a Bad AI Decision Actually Costs
The tokens a wrong decision burns are the cheapest part of it, and close to the only part that lands anywhere you can see.
Ask a team what their last bad AI decision cost them and you get one of two answers. Most give you a shrug. The ones with good instrumentation give you a token number: this workflow ran long, it retried four times, here is the spend.
That number is real. It is also, for most of the decisions worth caring about, off by orders of magnitude, and wrong in a specific direction. It captures the cheapest thing that happened.
I have written before about the gap this sits inside: execution is observable, decisions are not. What that gap does to a balance sheet is less discussed. The money does not disappear. It lands, in full, in six different places, on six different clocks, under owners with no reason to connect any of it back to the moment a system chose wrong.
The rule that manufacturing figured out first
Quality management has a rule of thumb, sometimes called the rule of ten: a defect caught at design costs a fraction of one caught on the production line, which costs a fraction of one that reaches a customer. The specific multipliers vary by industry and most of the numbers attached to them are closer to folklore than measurement.
The structure is not folklore. The cost of a defect is a function of how far it travels before anyone notices, because distance is what determines how much got built on top of it.
AI systems inherit that structure and then make it worse in one specific way. A production line makes a bounded number of decisions, and most of them are inspected. An agent makes many decisions per task, continuously, and almost none of them are inspected individually. The travel distance is longer and the inspection rate is lower, which is the exact combination the rule of ten warns about.
Six places the money lands
Take one wrong decision and follow it forward rather than backward.
The decision itself. The tokens spent producing the wrong choice. This lands within seconds, on the bill, and it is genuinely indistinguishable from the tokens spent producing a right one. A good decision and a bad decision cost the same to make.
The recovery. Retries, re-retrieval, the agent going back around on something it already had enough in front of it to settle. This also lands on the bill within the same minute, filed as usage rather than as rework, because nothing in the billing model has a category for rework.
The downstream execution. Everything the system then did correctly, on a wrong premise. This is the first component large enough to notice, and it is the first one that gets attributed to the wrong thing: it shows up under whatever workflow ran, not under the decision that set it running. Perfectly efficient execution of a bad choice is still waste, and it bills as throughput.
The detection. Engineering hours at the surfacing end. Someone works backward from a symptom, and every step they pass through on the way there looks correct, because each one was. This does not appear on the AI bill at all. It appears on payroll, days or weeks later, usually filed under an incident that names the symptom rather than the cause.
The correction. The fix, plus the standing tax of whatever guardrail gets added to prevent a recurrence. Guardrails are not free. Every one of them is latency and complexity that the system carries forever, paid for by a decision that happened once.
The forfeited scope. The work you decide not to hand the system next time. A team that gets burned narrows what it delegates, and that narrowing is permanent until something changes their mind. This is almost certainly the largest number of the six, and it is the only one that appears in no ledger anywhere, because it is not a cost that gets incurred. It is a benefit that never gets collected.
The ordering is the finding. Those six arrive in roughly ascending order of size, and in strictly descending order of visibility. The cheapest component is the only one anyone can point at.
A worked example
Sanitized, and deliberately mundane, because the expensive cases usually are.
A support agent triages inbound tickets by entitlement. A customer writes in about a charge they did not expect after a plan change. The agent reads this as a billing dispute and routes it to the disputes workflow. The other available reading, a service credit request under an existing entitlement, was equally defensible on the text. Nothing about the decision is anomalous. Both interpretations are ones a competent human would consider.
The disputes workflow is heavier. It pulls account history, runs a verification pass, and drafts a response with a different tone and a different set of obligations. All of it executes correctly. The customer gets a coherent answer to a question they did not quite ask, and either accepts it or writes back, which starts the whole thing again from a worse position.
Multiply that by the ticket volume that shares the same ambiguity, and the interesting cost is not the misroute. It is the disputes workflow running thousands of times on cases that were never disputes.
Nobody finds this by looking at the bill. The bill says disputes volume is up.
| Cost layer | Where it lands | When it lands | Attributed to the decision? |
|----------------------|-------------------------------|------------------|------------------------------------------------|
| The decision | AI spend | Seconds | No, it looks like any correct call |
| Recovery loops | AI spend | Seconds to hours | Filed as usage, never as rework |
| Downstream execution | Another workflow's line item | Minutes to days | No, credited to what ran, not what chose |
| Detection | Engineering hours | Days to weeks | Only if someone traces it back by hand |
| Correction | Hours, plus permanent latency | Weeks | To the incident, not the decision class |
| Forfeited scope | Nowhere | Quarters | Never, no system records a benefit uncollected |Why the accounting cannot close
Two separations do the damage, and neither is a tooling oversight that gets patched next quarter.
The first is time. The top three layers land inside a minute. The bottom three land days to quarters later. By the time the expensive part arrives, the cheap part has been aggregated into a monthly number and the causal thread is gone.
The second is boundary. The top three land in the AI budget. The next two land in payroll. The last one lands nowhere at all. Those are different systems, owned by different people, reconciled on different cycles, with no shared key between them. No accounting system joins a token to an engineer’s afternoon three weeks later, and there is no reason anyone would have built one.
So the cost gets split across ledgers that cannot see each other, and every ledger is individually correct. The AI bill correctly reports spend. The incident record correctly reports hours. Neither is wrong. Together they still fail to say that one decision, made in a fraction of a second, caused both.
The instrumentation gap has a financial twin, one level up. A trace is a record of steps, not of choices. A ledger is a record of amounts, not of reasons.
What you can actually estimate, and what you cannot
I want to be careful here, because this is exactly the point where a piece like this usually starts inventing precision.
You cannot measure most of the six. You can bound some of them, and the honest framing matters more than the arithmetic:
Downstream execution is recoverable, but only if you can identify the originating decision, which is the hard part and the whole problem. The compute is already logged. What is missing is the link from it back to the choice that triggered it.
Detection and correction are the most tractable, because incident records already hold rough hours. They are just filed against symptoms, so recovering them means re-attributing existing data, not collecting new data.
Recovery loops can be approximated by comparing a workflow’s actual path against its shortest successful path, which is an estimate and behaves like one.
Forfeited scope cannot be measured at all. It is only ever visible in what a team quietly stops automating.
Anything that hands you a clean dollar figure per bad decision is estimating, and should say so on its face. The useful output here is not a number. It is a ranking: which decision patterns are expensive, and roughly by how much, relative to each other.
The unit that is missing
Every AI cost tool I have used reports cost per token, cost per call, cost per workflow. Those are consumption metrics. They tell you what the system used.
None of them report cost per decision, which is the only unit that tells you what the system wasted.
That is not a gap in the tools. It is a gap in what the tools can see. Consumption is observable from the outside; a decision’s quality is not, and you cannot build a cost-per-decision number on top of a stack that has no representation of the decision in the first place. This is the direction I am building Nalyqor toward, and I would rather it be the direction the whole category goes: cost attribution that resolves to the choice rather than to the call.
In closing
The reason bad AI decisions feel cheap is not that they are cheap. It is that their price is paid in six installments, five of which arrive after anyone has stopped looking, in currencies that do not convert.
Teams optimizing AI spend right now are optimizing the one installment that arrives first and costs least, because it is the only one denominated in something the invoice understands. That work is not wrong. It is just aimed at the one installment the invoice can denominate, on a total nobody has actually computed.
An invoice is not a measurement of a mistake. It is a receipt for the cheapest part of one.