The cost of an AI agent per task is its full monthly run cost divided by the jobs your team accepted. That full cost includes the model bill, the people who review the output, the jobs that get redone, and the time spent keeping the agent running. The model bill is usually the smallest of those. It is also the only one the vendor sends you.
Whoever proposes an agent will quote token cost per run, because that is the number on the console. You need cost per accepted job, because that is the number you can set beside what the work costs when a person does it, and it is the number that tells you whether to fund the agent, fix it, or stop it.
The invoice is about a third of the cost
Two recent estimates agree on the shape. EY puts the token at roughly a third of what an agent actually costs to run, and lists the parts that usually go unbudgeted: oversight and risk controls, workforce changes, failed attempts and recovery, and compliance.1 McKinsey, modeling a banking customer-service agent, puts tokens at 20 to 25 percent of variable run cost and human oversight at 70 to 75 percent.2 Both are modeled estimates for particular cases, not benchmarks. They point the same way: the people around the agent cost more than the model inside it.
Your vendors cannot show you this. Microsoft, Anthropic, and Google meter by workload, group, or project. None of them knows how many of the agent’s outputs your team threw away, or how long the review took. That data lives with the workflow owner, which is why the cost allocation rule charges metered work to the workflow and its owner in the first place.
Count five costs and divide by accepted jobs
Ask the agent’s owner to fill in five lines for one month.
| Line | What goes in it |
|---|---|
| Model and tools | Metered API or agent usage, plus any connector or tool fees |
| Review | Hours people spend checking output, times their loaded hourly cost |
| Exceptions | Jobs the agent got wrong or could not finish, and the time to redo them |
| Operations | Platform share, monitoring, and the owner’s time keeping it running |
| Failure and recovery | Cleanup after anything the agent did that had to be undone |
Then divide the total by accepted jobs: outputs that a person or a check took and used without redoing them. Jobs the agent ran count in the volume chart. Only accepted jobs count in the denominator.
A worked example
Take a support-triage agent that handles 4,000 tickets a month. The figures are illustrative, but the proportions are typical of what the estimates above describe.
- Model and tools: $1,200.
- Review: a person spot-checks 15% of tickets at six minutes each. That is 60 hours at a $60 loaded rate, $3,600.
- Exceptions: 5% of tickets, 200 a month, get routed wrong and take a person fifteen minutes to fix. That is $3,000.
- Operations: a share of the platform and a few hours of the owner’s time, $1,500.
- Failure and recovery: one bad batch a month that someone has to unwind, $700.
The total is $10,000. Accepted jobs are 3,800. The agent costs about $2.63 per accepted ticket. If a person triaging a ticket takes ten minutes at the same rate, that is $10. The agent is worth funding.
Now look at where the money is. The model is 12% of the cost. Halving the model price, by routing to a cheaper model, saves $600 a month. Halving the exception rate saves $1,500 and adds 100 accepted tickets to the denominator. Cutting the review sample from 15% to 8% once the agent has a clean quarter saves almost $1,700. The cheapest model is rarely the biggest lever. The biggest lever is a verifier good enough that people can trust more of the output without reading it.
The number makes four decisions
Cost per accepted job, set against the cost of the same job done by a person, sorts every agent into one of four calls.
Fund it when the agent’s cost is well under the human cost and the exception rate is stable or falling. Give it more volume.
Redesign it when review or exceptions are most of the cost. The agent is doing the work but nobody trusts it. Build the check that lets the review sample shrink, or narrow the job to the cases it gets right.
Route it to a cheaper model only when the model line is a large share of the cost and the accepted rate holds on the cheaper model. Test that on a sample before switching, because a cheaper model that raises exceptions costs more.
Stop it when the cost per accepted job is near or above the human cost after a quarter of trying to fix it. A running agent that saves nothing still carries risk, and the agent register should record its end date.
Put it on the dashboard
Cost per accepted job belongs on the spending dashboard, one row per agent, next to the metered spend it already shows. It turns the spend cap from a ceiling on tokens into a ceiling on cost per useful result, and it gives the returns conversation a figure the finance team can check.
The sentence for your agent owners: tell me what each accepted job costs, review and redo included, and what it costs when a person does it. The sentence for the board: we price every AI agent by the work it delivers, not by its bill, and we stop the ones that cost more than the people they were meant to help.
Footnotes
-
EY, “Agentic AI ROI: Can AI pay for itself?”, September 21, 2026. ↩
-
McKinsey QuantumBlack, “Where AI agents pay off: A practical guide to the economics of agentic workflows”, August 24, 2026. ↩