YOUR AGENT'S REAL PRICE IS COST PER TASK.

WHAT HAPPENED

Gartner published a prediction on 17 August: inference cost per agentic workflow will rise more than fivefold through 2028, at the same time as the price per token keeps falling. They call it the inference paradox. Senior director analyst Will Sommer's framing is that each new generation of capability needs more tokens, and often more expensive ones. The recommended fix is tiering, routing and orchestration. A day later Snowflake shipped exactly that: dynamic model routing in its Cortex AI Gateway, choosing a model per request against complexity and cost instead of sending everything to the largest one available.

THE UNIT EVERYONE IS BUDGETING IN IS WRONG

Per-token pricing is the metric vendors quote because it is the one that keeps improving. It is also nearly useless for planning, because it prices an input you do not control while hiding the variable you do.

A chatbot answers in one call. An agent reads a ticket, queries three systems, drafts, checks itself, retries a failed tool call, and writes back — twenty calls, some of them long. Halve the token price and triple the call count and your bill goes up. That is not a pricing failure, it is what capability costs; the mistake is measuring it in the wrong denominator.

The number that survives contact with a CFO is cost per completed task: total inference spend for a period divided by the number of workflows that finished correctly without human rescue. It is the only figure that can be compared to the thing the agent replaced — the loaded hourly cost of the person who used to do it.

COST PER TASK IS INSTRUMENTED, NOT ESTIMATED

• Instrument at the workflow, not the call. Tag every model call with a workflow ID from day one of the pilot. Retrofitting this later is painful and everyone postpones it.
• Count failures in the denominator. A run that a human had to redo is not a completed task; it is two costs and a completed task. Programs that exclude these report numbers that fall apart at scale.
• Watch the distribution, not the mean. Agent costs are long-tailed. A handful of pathological runs — retry loops, oversized context, a tool that times out and gets called again — carry a disproportionate share of the bill. They are also the cheapest thing to fix.

Once the number exists, the fix is unglamorous. Most steps in a workflow do not need a frontier model. Classification, extraction, formatting, routing decisions and summarization of short inputs run fine on a small fast model. Reserve the expensive one for the two or three steps that genuinely require reasoning over long context.

One platform has moved: Snowflake’s stated design for dynamic routing is to pick a model per request on quality, speed and cost. If your stack sends every request to the largest available model instead, you are paying a premium on every run, forever, at whatever volume you eventually scale to.

This is also where a written decision boundary pays for itself twice. Steps an agent executes unattended need to be cheap and fast because nobody reads them. Steps that produce a draft for a human can afford a better model, because the review catches what the model misses. The governance document and the cost model are the same document.

A VENDOR SHOULD PRICE YOUR WORKLOAD, NOT ITS TOKENS

Three questions, in order. What is the cost per completed task on a workload like mine? Can I route steps to different models, or is the model fixed at the platform level? What happens to that number when volume goes up 10x — does anything about the architecture change, or does the bill simply multiply?

Any agent whose cost per completed task you cannot state is not finished. It is a demo with a good week behind it.