Cloud computing taught companies a lesson that is now arriving again with agents. A service billed by use is cheap when you start and unpredictable when you succeed. The team that celebrated a successful launch learns about the bill at the end of the month, and the number does not match anything anyone planned.
An agent is billed by use in more ways than the cloud ever was. It consumes model tokens, calls tools, retries and waits, and each of those has a price. The cost of a run depends on the task, the data, the model and, most awkwardly, on whether the agent got stuck. A working agent costs what it costs. A failing one can cost more.
The discipline for managing this has a name borrowed from the cloud, FinOps, and for a company with its first agents it comes down to three controls.
Software is bought by the seat or the licence, and the price is the same whether it is used or not. An agent is bought by the unit of work, and the unit is not fixed. We described the components of a monthly bill in what an agent costs a 100-person company a month: tokens, operations and the people who keep it honest. What matters here is that each is variable.
Three things make agent cost behave badly.
Failure costs money. A run that fails halfway has already spent its tokens. A run that loops, retrying a tool that returns an error, spends them again and again. In a human process failure costs time. In an agent process it costs time and a metered amount, and the agent never gets tired.
Cost follows context. A task that carries a long thread, a large document or a whole customer history costs more than the same task with a summary. Nobody chose that. It is a consequence of what the agent was handed.
Cost grows with success. An agent that proves useful gets more work. A company that planned for fifty runs a day finds itself at five hundred, and the cost scaled with them. That is the right outcome, and it needs a budget that expected it.
Every agent run writes a record: which agent, which task, when it started and ended, how many tokens it used, how many tool calls it made, the model, and the cost computed from the current price. One row per run, in a table the finance owner can read.
Three views come from it. Cost per run, by agent, so you know what a unit of work costs. Cost per outcome, which divides the cost by a result that matters, such as an invoice raised or a ticket resolved, and is the number to compare with the cost of doing the work by hand. And cost by process owner, which attaches each agent's spend to the person responsible for the process it serves.
The meter is the foundation. Without it the other two controls have nothing to read. It is also the easiest to postpone, because the platform's bill appears without it. The platform bill tells you how much was spent. Only the meter says what it was spent on.
A cap is a limit that stops spending. It has two parts, soft and hard.
The soft cap is a threshold, such as eighty percent of the monthly budget for an agent, that sends a message to the process owner. Nothing stops; somebody is asked whether this is expected.
The hard cap is a ceiling at which the agent pauses until a person approves more. A paused agent is a nuisance. A loop that spends a month's budget overnight is a worse one. The hard cap is set above any plausible legitimate use and below anything that would be a surprise on the bill, and the person who can lift it is named.
Caps work at several levels. Per run, such as a maximum number of tool calls, which stops a loop at its tenth retry instead of its ten-thousandth. Per day, per agent. And per month, across all agents. Per-run caps do most of the work, because loops are the main risk and they happen inside one run.
A cap handles the known worst case. An alert handles the unusual one. The simplest rule is a comparison with the trailing average: an agent whose daily cost is more than twice the average of the previous fourteen days sends a message to its owner. A change in cost per run, or in the share of runs that fail, does the same.
Alerts are most useful for what they find that is not a loop. A change in an upstream system that makes every record larger. A new data source that doubles the context. A prompt change that doubled the tool calls. A task that was meant for a hundred runs a week being triggered by a rule that fires every minute. In each case nothing is broken, and the cost is moving, and somebody wants to know on the day.
Every agent needs a named cost owner, and it should be the person who owns the process the agent serves, not the technical administrator. The administrator can explain why a run cost what it did. Only the process owner can say whether the outcome was worth it. This is the same operator role we argued for in what an AI agent costs to build and run: the integration and operations lines on an estimate are the cost of someone watching.
A monthly ten-minute review per agent is enough: cost per outcome against last month, caps hit, alerts raised, and whether the budget for next month should change. When the agent is working, the review is quick, and it is the moment the owner decides to give it more work.
Expect three findings in the first month. One agent spends most of its money on a handful of runs with very long context, which a summary step cuts sharply. One task fires far more often than its owner thought, because a rule upstream was broader than intended. And the cost per outcome is better than the owner feared for one agent and worse for another, which settles where to put the next unit of work. None of this needed new tooling, only the rows the meter wrote.
Pick your busiest agent. Make sure each run writes a row with tokens, tool calls, duration, model and cost. Set a per-run cap on tool calls. Set a daily soft cap and a monthly hard cap. Add the twice-the-average alert on daily cost. Name the owner and schedule the review. That is the entire discipline for one agent, and it generalises to the second without change.
We run the meter, the caps, the alerts and the monthly review as part of the managed agent layer for companies of 5 to 1,000 users, and the usage tier is priced with them in mind. Discovery is no-risk: we set up the meter on your first agent and show what a unit of its work costs, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.
An agent's bill is not a surprise to be explained at the end of the month. It is a number someone watches every day.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
