The question that has no single answer
You are explaining an AI implementation to the team that will use it. One model costs less per call; another needs fewer corrections. Which one belongs in the workflow? Start by separating token spend, review time and usable results. The average bill per run is a real number, but it does not answer that routing decision on its own.
What does one unit of output actually cost?
Cost accounting distinguishes several questions that a single average can blur. This article uses that distinction to reason about an agent workflow; it does not depend on a claim about who first introduced it.
What did this absorb of total cost? is a different question from what does one more unit add? — which is different again from what would disappear if we stopped doing this altogether?
A number useful for allocating the total bill may be unsuitable for deciding whether to run one more task.
Apply those decision levels to an agent workflow. Inference can be metered in tokens; review consumes a person's time. A useful implementation record keeps both, along with whether the result was accepted. A token log alone is not that record.
The engineering task is to connect these observations to a unit of work. The accounting distinction then helps you explain which costs the next run causes and which belong to keeping the workflow available.
The finding that reorganises everything
For a routing decision, compare what an accepted result is worth with the additional resources needed to produce and review it. This contribution view complements the total-cost view needed to decide which capacity to maintain.
The following example makes its accounting assumptions explicit:
For this argument, assume the rejected output has no reusable value. It consumed tokens and review time without producing a usable result. Under that assumption its contribution is negative.
A failed experiment can still teach you something, and a partly correct result may be repairable. Record that value and the rework explicitly; do not count either as a completed deliverable.
For an operational comparison, count outputs accepted against the task's criteria, not merely outputs generated. State what the checks cover. Passing a schema check is not evidence that every factual claim is correct.
What your cost-per-task dashboard leaves out
If your dashboard divides total spend by run count, inspect what that total includes: task calls, orchestration, retries and standing context may be mixed together. Using the resulting average for every task allocates those costs by volume.
Suppose one task needs a single call and another needs several calls plus a long review. A shared average conceals that difference. Keep their observations separate before comparing routes.
Standing costs also change the interpretation. If a fixed subscription is allocated across fewer runs, its allocated cost per run rises even when the next run consumes the same resources. Cutting useful tasks in response can raise that average again. State the fixed-cost assumption before using this example to explain a real dashboard.
The streetlight fallacy, in cost-accounting form
Tokens are the visible, metered block. Measure the other inputs before assuming they are smaller.
Review minutes, orchestration, standing context and rework can dominate an operated workflow. A cheaper model can raise total cost if it creates enough extra review. Whether it does is a question for your cases and acceptance criteria, not the model's price list.
Minimising the metered factor because it is the metered factor is looking for your keys under the streetlight.
Here's a hypothetical that illustrates the mechanism, not a measured result: a cheap model that ships work only 80% of which passes verification can be strictly dominated in margin terms by a model at three times the token price, once you price in the review minutes the failing 20% costs.
The comparison needs a review-time estimate, a value for that time, and acceptance rates for both models on the same tasks. Without those inputs, the 80% and three-times-price figures are an illustration of the tradeoff, not enough arithmetic to select a model.
Measure those inputs before recommending a route. A lower token price alone does not settle the comparison.
Cost attaches to a decision, not to a thing
When someone says "an agent costs X per task," ask which costs they included: marginal inference, subscriptions, orchestration or development. The same label can hide different accounting choices.
The missing discipline is attaching each cost to the level of decision that causes it:
| Level | What it carries | The question it answers |
|---|---|---|
| The task | tokens, the review minutes it consumed | should I run this one? |
| The stream | standing context, memory maintenance, monitoring | should this workstream exist? |
| The org / the period | subscriptions, orchestration, the tooling | what capacity should we hold at all? |
And the practical consequence is the layered margin statement: a task can be margin-positive while the stream it belongs to is not covering its own readiness costs.
Conflating the layers can mislead a decision: an allocated charge may make a useful extra task look unattractive, while low incremental cost may conceal expensive standing capacity.
A workflow can be cheap to run once and expensive to keep ready. Make that distinction visible in the handover, so the receiving team can decide which capacity is worth maintaining.
Isn't this just Taylorism with better sensors?
The question deserves a straight answer, because the objection is serious and the answer is not obvious.
The concern is how a measurement gets used. A review-time record can show that a workflow creates extra checking. The same record can also become a way to rank or pressure workers. This article argues for diagnosing the workflow, with the people doing the review involved in deciding what is measured and how the record may be used.
For software runs, collect the operational evidence needed to diagnose failures and account for resources. Logs may contain personal or confidential data from the task; an agent's involvement does not remove the need to limit access, retention and recorded content.
Treat review minutes as work the workflow requires, with its context attached.
Use the record to ask which outputs create avoidable review and rework. Do not treat fewer minutes as proof of better judgment, or turn the record into a performance ranking. State the purpose and limits of collection with the people doing the review.
What smart people get wrong
What to actually track
Start with four fields per work product. A short manual record can be enough:
If your tool exposes usage, record it and what it includes: task calls, retries or orchestration. Mark missing usage as unknown. Do not substitute an estimate without labeling its assumptions.
Time spent reviewing, correcting and re-running. Keep these observations separate from token spend so a lower inference bill cannot hide extra work for the receiving team.
Record first-pass acceptance separately from whether the checks ran and detected known failures. A rejected output can demonstrate that verification works. A lower first-pass rate may increase rework; measure the actual extra work before attributing a cost change to it.
Task, stream, or standing capacity. One word. It's what stops you conflating them later.
Keep a short record when each work product finishes. Compare like tasks under the same acceptance criteria, then explain the routing or capacity decision using that evidence. The record makes the tradeoff inspectable; it does not supply a universal price for a minute of someone's time.
A changed model, price or acceptance rule can change the comparison. Retain the date, task set, cost categories and review-time assumptions so the next person can repeat it. The useful habit is separating decision levels, then checking whether the measurements still support the choice.
The mechanics of the token side: what drives the bill, which dials move it, and the ledger line to keep per work product.
