The agency tax: the same AI invoice can hide one dollar of rework or ten

Every one of them stops at the same boundary, which is the provider’s invoice.

When an agent fails, the invoice charges you for the retry. It does not charge you for the engineer who noticed, for the verification that caught it, for the rollback, or for the downstream work that ran on a bad result before anyone saw. That cost is real, and it is off the invoice by construction.

Call it the agency tax: the true cost of a failure, not the visible slice of it. When a failure changes the environment, the rework can cost more than doing the task from scratch, and the rework is what decides whether it is safe to let an agent run unattended.

This is an old idea with a new meter

I want to be precise about what is new here, because it is less than it might look.

Manufacturing has split failure costs this way since the 1950s, when Joseph Juran, the quality engineer whose methods rebuilt post-war Japanese industry, argued that the hidden half of the cost of poor quality was where the money actually went. Barry Boehm measured the same effect in software in 1981: the later you catch a defect, the more it costs to fix, rising sharply from design to production. The 1-10-100 rule made it a slogan in 1992, a dollar to prevent a defect, ten to fix one you caught, a hundred once it reached the customer. Ward Cunningham, who coined the term technical debt that same year, added that the interest rate depends on what kind of shortcut you took.

The agency tax is that seventy-year-old accounting, pointed at AI calls a meter can see.

What changed is the instrument, not the theory. All of that work estimated the visible half from surveys and post-mortems, after the fact. With metered calls you can read it straight off the meter, per workflow, while the work is running. The floor stops being a study and starts being a number you already have.

What we can measure, and what we can’t

We split the agency tax into two parts and label which is which, because the split is the honesty of the whole thing.

The measured floor is the retry tax: tokens burned redoing failed work, read from the metered calls. It is real, it sits on the invoice, and we report it as measured. It is also the cheap half.

The estimated total scales that floor by a cascade factor keyed to how the domain fails. A single multiplier for everything would be a lie, because not every failure propagates the same way, so we key it to quality elasticity, which classifies work by how well it verifies and how cheaply it can be redone. Each class carries one number, the multiplier you apply to the measured floor:

• Elastic work is cheap to verify, cheap to redo, and rarely changes anything downstream. Multiply the floor by 1.2, so the agency tax is barely more than the visible retry.
• Moderate work carries some verification and rework beyond the retries, with limited propagation. Multiply by 1.8.
• Brittle work verifies weakly, and its errors travel downstream before anything catches them. Multiply by 3.0, and this is the only one of the three where the off-invoice half is bigger than the retry you can see.

Until someone has looked at a domain and placed it in one of those three classes, we use 2.0, and I should be blunt about what that means. On day one, before anyone has done that work, every workflow gets the same 2.0. That is a flat multiplier, the exact thing I just said not to trust, and it stays flat until somebody sits down and classifies the domain. Labelling it as the ignorance case is what stops it being passed off as a finding. It is conservative rather than optimistic, and it does not resolve to the cheap end merely because nothing is known.

These are working priors, not measured rates. They are versioned and changed deliberately rather than tuned to flatter a result, but nobody should mistake that discipline for verifiability. You cannot check 3.0 against a vendor’s published page the way you can check a token price.

The part that makes this checkable

Here is what a vendor inventing a scary number would leave out. The off-invoice rework cannot be read from call data, because it is by definition off the invoice. No amount of token telemetry recovers the engineer-hours, the rollback, or the wrong decision made three steps downstream.

Take that with the skepticism it deserves. I build tooling in this space, so I have an interest in you believing there is a cost you cannot see.

Which is why the priors need a way to be wrong. There is one place the cascade stops being an estimate: a multi-agent pipeline. When an upstream stage fails and later stages keep running, that downstream spend lands on the invoice and is attributable to the chain that produced nothing. On those failed runs you can count, directly, how many dollars the later stages burned for every dollar the failed first stage cost. That ratio is the same quantity the cascade multiplier estimates, except measured. If work classed brittle keeps measuring near 1.1, the prior is wrong and belongs at 1.1.

I have not published such a measurement, so do not read the three constants as results. They are a starting point with a defined way to be replaced.

A worked example you can check

The numbers are illustrative, chosen so the arithmetic is easy to follow. Take a workflow that spent $100 last week with a measured retry tax of 5%, so $5 of visible, on-invoice waste. That $5 is the floor, and it is all a token dashboard shows you.

If the work is brittle, the estimated total is $5 × 3.0 = $15: the $5 you can see, plus $10 you can’t. If the same $5 floor sits in elastic work, the estimate is $6, and the invoice was nearly the whole story. Identical invoices, two and a half times the difference in true cost, decided entirely by how the work fails.

That is the actual finding, and it is smaller and more useful than “your costs are triple.” The invoice cannot tell you which of those two workflows you are looking at. Nothing on it moves between the $6 case and the $15 case.

If our multiplier is wrong for your domain, put your own in. The decomposition is the part that matters and the constant is an input to it.

Why this is the number to govern on

Autonomy is a bet that an agent’s work is worth more than it costs. Priced on the invoice, the bet looks the same in both cases above, because the invoice is identical in both cases. Priced on the agency tax, a brittle workflow that looks efficient on tokens can be the most expensive thing you run. That is the number that should decide whether the loop stays on.

I have told you which half was measured, which half was estimated, the multiplier I used, and the one case where it can be checked against real spend. Ask that of any number anyone hands you about the cost of AI, this one included.

Margin measures cost per completed outcome across providers, and refuses a cheaper route when quality slips. How it works · See it live