Cheap per run. Expensive per result.

The number that retired the token report

Run the arithmetic once and the old metric never recovers. Agent A costs $0.10 per execution and completes the task correctly 70% of the time. Agent B costs $0.40 per execution and completes it 95% of the time. On the cost-per-run report — the one most AI programmes still send upstairs — Agent A is the obvious winner, 4x cheaper. Now add the only number that report omits: what a failure costs. Say a failed case takes a human $5 of time to detect, unwind and redo — a conservative figure for anything touching an invoice, a claim or an onboarding file. Agent A's real cost per successful task is ($0.10 + 0.30 × $5) ÷ 0.70 = $2.29. Agent B's is ($0.40 + 0.05 × $5) ÷ 0.95 = $0.68. The agent that looked 4x cheaper is more than 3x more expensive — per result, which is the only unit anyone upstairs is buying.

That is the whole shift, and it is why the board conversation moved in 2026. The executive reviewing an agent programme does not want cost-per-token any more than they ever wanted cost-per-CPU-cycle. They want cost-per-resolved-case, cost-per-processed-invoice, cost-per-decision — and they want it adjusted for the rate at which the agent actually resolves, processes and decides. CFO surveys through the year converged on the same finding: a clear majority say agents have changed how they evaluate technology ROI, because an agent that does work is not a software line item — it is digital labour, and labour has always been priced by output, not by effort. A note on scope before going further: this is not the question of what you charge the customer — we covered that in outcome-based pricing — and it is not the gross-margin question of inference entering COGS. This is the internal metric: the unit economics that decide, in a board meeting, whether the agent scales or gets cut.

The denominator is success, not execution

Cost-per-successful-task looks like a cosmetic change to a formula. It is not — it is a change in what the formula punishes. Cost-per-run treats every execution as equal: the run that closed the case and the run that produced a wrong answer a human spent 20 minutes unwinding both count once in the denominator, and the second one actually makes the metric look better, because it adds volume. Put success in the denominator and the failed run flips sign: it adds cost to the numerator — its own inference, the retry, the human rework — while adding nothing below the line. Failure stops being invisible and starts being expensive, on paper, where budget decisions are made.

Cost-per-token measures what you spent. Cost-per-successful-task measures what you bought. A board can only govern the second number — and a team that only reports the first hasn't told the board anything it can act on.

This is also where the metric connects to the reliability conversation. We argued in the agent reliability gap that production success rate per intent — not benchmark capability — is the number that separates agents that scale from demos that stall. Cost-per-successful-task is that same number wearing a finance hat: the success rate is the bridge between the two, because it is simultaneously the engineering SLO and the divisor in the unit economics. A programme that does not measure its success rate in production cannot compute its real unit cost. It can only report spend — which is precisely why so many do.

Agent FinOps, piece by piece

Teams that report a credible cost-per-successful-task did not get it from the billing console. They built a small discipline around it — agent FinOps — and its components are consistent enough to list.

The full numerator: inference + tools + review + error. The cost of a task is not the cost of the model call. An agentic flow burns inference across a loop of steps — we priced that loop in the token tax — but it also calls paid tools and APIs, consumes human minutes whenever a case routes to review, and, when it fails silently, generates the most expensive line of all: the cost of the error itself — the mispaid invoice, the compliance finding, the customer call. A numerator that stops at the token bill understates the real cost by a factor that grows exactly when the agent gets worse — which is the moment you most need the metric to be honest.

The success-rate multiplier. Divide by the success rate and every point of reliability becomes a finance lever. At a $1 all-in cost per run, moving from 85% to 95% success cuts the cost per outcome by more than 10% before counting the rework saved — and the rework is usually the bigger term. This is the multiplier that makes reliability engineering fundable: it converts "the agent should fail less" from an engineering preference into a line with a payback. It also penalises the right things — an agent tuned to attempt everything and escalate half of it stops looking productive the moment escalations are priced in.

The honest human baseline. Cost-per-successful-task only means something against the alternative: what does the same task cost when a person does it, fully loaded — wage, overhead, error rate (humans have one too), and the queue time that delays the outcome? The comparison has to be honest in both directions. Inflating the human cost to flatter the agent produces a business case that dies on contact with the CFO's own numbers; ignoring the human error rate flatters the human. Done straight, the baseline tells you something more useful than "is the agent worth it" — it tells you the success rate below which it is not, which is the threshold the whole programme should be managed against.

A board view in outcomes, not consumption. The artefact that lands is not a token dashboard — it is a short table per flow: cost per resolved case, success rate, trend over 90 days, human baseline alongside, and the operating capacity the delta freed. That last column matters more than it looks: "each resolved case costs $0.68 against a $4.10 human baseline, at 95% success, across 140,000 cases a quarter" is a sentence about capacity, and capacity is the language in which the board approves scale. It is the same lesson the ROI gap data taught at programme level — returns follow outcome ownership, not spend — compressed into a unit metric.

Four ways the token metric sinks the conversation

The failure modes here are not exotic. They are four reasonable-looking reporting habits that each hide the same thing: the cost of failure.

• Optimising cost-per-token while the success rate pays for it — the team switches to a cheaper model, the token bill drops 40%, the success rate drops 8 points, and the rework queue silently absorbs the difference at human hourly rates. The programme celebrates a saving that is actually a cost increase — per result — and nobody can see it because the only chart in the deck is denominated in tokens. Every model and routing decision should clear one bar: did cost per successful task go down?
• Keeping exception and review cost outside the unit economics — human review sits in the operations budget, rework in the quality budget, and the agent's reported unit cost covers inference alone. The agent looks cheap precisely because its failures are funded elsewhere. The test is simple: if the agent's success rate dropped 10 points tomorrow, would its reported cost per task move? If not, the metric is decorative.
• Promising ROI without measuring production success rate — the business case was built on a pilot accuracy figure, the programme scaled, and nobody instrumented the denominator. Six months later the board asks whether the promised return materialised and the honest answer is that nobody knows — the spend is documented to the cent and the outcomes were never counted. This is the unit-economics version of the pilot-production gap: the measurement layer was the deliverable, and it never shipped.
• Comparing the agent to software when the board is pricing labour — the deck benchmarks the agent against per-seat SaaS and declares it expensive; the board, meanwhile, is reading it as a digital worker and wants the cost per task against the loaded human cost. The category error cuts both ways: priced as software, a good agent looks costly; priced as labour, a bad one looks cheap. Pick the labour frame and defend it with a measured success rate — because that is the frame in which the decision will be made with or without you.

The trade-off, stated honestly

The metric forces a trade-off that the token report let everyone avoid: cheaper per run versus cheaper per result are different optimisation targets, and they frequently point at different architectures. The cheapest-per-result configuration often spends more per execution — a stronger model on the hard 20% of cases, a verification pass before anything writes to a system of record, a confidence threshold that routes borderline cases to a human instead of guessing. Each of those raises the per-run line that procurement watches and lowers the per-outcome line that the P&L experiences. We made the architectural case for that split in reasoning models for document AI — pay for depth only where difficulty justifies it. The unit economics close the loop: the router that sends 80% of volume to a fast model and 20% to a deep one is not a cost optimisation and a quality optimisation in tension; it is one decision, evaluated on one number.

Honesty also requires the other direction. Not every flow earns the expensive treatment. A draft-only flow where a human reviews every output anyway can run at a lower success rate without the failures costing much — the review was already priced in. And the multiplier cuts both ways at the top: pushing from 95% to 99% success can cost more in engineering and inference than the saved rework returns, if the failure mode is cheap. Cost-per-successful-task does not say "maximise reliability"; it says price reliability — and let each flow buy exactly as much of it as its failures cost. That is a judgment the token report could never even pose.

The sentence that wins the board meeting

Two teams present the same agent programme. The first reports: "we spent $180,000 on inference this quarter, 22% under budget." The second reports: "each resolved case costs $0.71, against a $4.20 human baseline, at 94% success — the ROI holds down to 78% success, and we alarm at 85%." The first team has reported its consumption and left the board to guess what it bought. The second has given the board a machine it can govern: a unit cost to compare, a baseline to beat, a threshold where the case inverts, and an early warning before it does. Same agent, same spend — but only one of those teams gets the scale-up approved, and it is not the one with the tidier token chart. The difference is not presentation skill. It is that the second team built the measurement — production success rate per flow, fully loaded numerator, honest baseline — and the first team, somewhere months earlier, decided the billing console was close enough.

Closing thought

Every technology that matters eventually gets repriced from effort to outcome. Compute was priced per machine, then per cycle, then per request; software per licence, then per seat, then per use. Agents are completing that arc faster than any layer before them, because what they sell was never software in the first place — it is work, and work has always had exactly one honest unit: the task, done, correctly. Cost-per-token was a procurement metric that wandered into a labour conversation. Cost-per-successful-task is the labour metric — and the teams that adopt it first don't just survive the board meeting. They find out, before anyone else, which of their flows actually make money.

At Cogneris we build for the metric, so here is our position stated plainly. Our platform measures the success rate per document class on your real traffic — including the runs that escalated to your review queue — because that denominator is the difference between a unit cost and a guess. Every run is traced and priced: extraction, verification, retries and human-review routing are visible per case, so your cost-per-resolved-document is a number you can read, not an allocation you negotiate. Confidence thresholds are configuration — you decide where a case is cheaper to route to a human than to risk a silent error, and the audit trail records which path every case took. And our pay-per-page pricing means your cost scales with what you process, while the success rate we report tells you what each processed page actually returned. If you want to know your real cost per resolved document — numerator, denominator and baseline — talk to our team: bring a month of real volume, and we will compute it with you.