Agent ROI: twelve steps cost twelve times a single call
An agent that takes twelve steps to answer a question costs roughly twelve times what a single call costs, takes roughly twelve times as long, and has roughly twelve opportunities to go somewhere unhelpful. None of that is visible in a pilot, because a pilot runs at a volume where any per-request cost is affordable. It becomes visible on the first full invoice, at which point the system is in production, people depend on it, and the remaining options are worse than the ones available at design time. This is the most common reason a technically successful agent is quietly switched off, and it is entirely avoidable by ten minutes of arithmetic before building: expected steps, multiplied by cost per call, multiplied by expected volume, using the realistic step count rather than the happy path.
The arithmetic, and the number people use wrong
Cost per request equals steps multiplied by the cost of a call, plus whatever retrieval and tooling each step triggers. Annual cost is that multiplied by volume. There is no subtlety in the formula; the error is always in the step count.
Teams estimate with the path they designed, which is the case where everything is found on the first attempt. Real traffic contains the requests where retrieval returns nothing useful and the agent tries again, where a tool errors and it retries, where the question is ambiguous and it explores. Those runs are a minority by count and a majority of the bill.
The honest estimate uses the mean step count including the tail, and the only way to know that before launch is to run the agent on a sample of real inputs rather than on examples somebody chose. Fifty real requests will tell you, and the difference from the designed path is routinely a factor of two or three.
Reducing steps beats reducing cost per step
When the number is too high, the reflex is to look for a cheaper model. That is the second lever and usually the smaller one.
Step count drives three things at once: cost, latency, and the probability that something goes wrong somewhere in the chain. Removing four steps improves all three. Switching to a model that costs thirty per cent less improves one of them and frequently increases the step count, because a weaker model needs more attempts.
The steps that usually come out are the ones added for completeness rather than necessity: a verification pass that never changes the answer, a planning step on a task with one obvious approach, a summarisation of something that was already short. Looking at fifty real traces and asking which steps changed the outcome is an afternoon that typically removes a third of the cost.
Cap the steps, and alert on the cap
A hard maximum on steps is the cheapest protection available and is frequently absent. Its purpose is not efficiency; it is to prevent the run that loops for an hour and bills for it.
The cap should be set well above the realistic mean, so it never fires in normal operation, and it should raise an alert when it does. How often it fires is one of the more informative numbers about a system: rising frequency means something upstream has changed, usually before any quality measurement notices.
The related discipline is a budget per request rather than only per month. A monthly budget tells you that you overspent. A per-request ceiling stops the single pathological run that consumed a tenth of it.
Latency is part of the bill, paid by someone else
Twelve steps is also twelve round trips. A system that answers in thirty seconds instead of three has not become more expensive on the invoice; it has become more expensive for the person waiting, and that cost lands on adoption rather than on finance.
In most contexts this shows up as quiet abandonment. People try the thing, wait, and go back to what they were doing. In contexts with a physical deadline, such as logistics, it is worse than abandonment: an answer that arrives after the cut-off is not a slow answer, it is no answer, and the design was wrong rather than slow.
The practical consequence is that the step count should be budgeted against a latency target as well as a cost one, and the tighter of the two constraints wins. Teams that budget only cost discover the other constraint from users.
When the honest answer is not to build an agent
If the arithmetic says the per-request cost exceeds what the task is worth, the design is wrong rather than the estimate. A workflow with a model in one step often achieves most of the outcome at a fraction of the cost, and the difference is not marginal.
This is worth checking before the build rather than after, because the cheapest possible saving is not building the expensive thing. Our page on agents sets out the test: try to write the steps down, and if you can, build that.
The value side of the calculation follows the same rules as any automation project, and the ROI calculator shows the arithmetic with every step visible. The input people get wrong there is the share of work genuinely handled end to end, and using an agent rather than a workflow does not improve that number. It only makes each attempt cost more.
