Where Agentic AI Gets Expensive
August 14, 2026 · PanaceaLogics Team
The first bill is never the problem. A pilot serving twenty people costs less than the meeting where you approved it, which is exactly why the cost conversation gets postponed.
The problems arrive later, and mostly not from the place people watch. Token spend is the line everyone monitors and it is rarely the one that hurts.
The multiplier nobody prices in
A chat completion is one call. An agent run is not.
A single user question can become a retrieval query, three or four tool calls, a reasoning step between each, and a final answer. Then the user asks a follow-up and the whole conversation history goes back through the model again.
Ten to thirty model calls per user request is normal for an agentic workflow. If you sized your budget on the cost of one completion, you are out by more than an order of magnitude before anything has gone wrong.
Worse, the multiplier is not fixed. A well-scoped question resolves in three calls. An ambiguous one sends the agent round the loop until it gives up or hits a limit. Your average is set by your least clear users.
Where the money actually goes
Ranked by how often it surprises the people paying.
| Cost | Why it grows | Usually noticed |
|---|---|---|
| Conversation history | Every turn resends the whole thread | Month two |
| Retrieval context | Ten chunks per call, most unread | Month two |
| Retry and failure loops | Failed runs cost full price | After an incident |
| Re-indexing | Embedding the same corpus repeatedly | First content migration |
| Human review time | Staff checking output | Never measured |
| Engineering maintenance | Evaluation, prompt and tool upkeep | At renewal |
The bottom two are the ones that matter most and appear on nobody’s dashboard, because they are salary rather than invoice.
If an agent drafts a reply in four seconds and a person spends three minutes verifying it, you have not automated the task. You have added a step. That can still be a good trade while trust is being established, but it should be a decision with a date on it, not a permanent state you drifted into.
Failure costs full price
This one catches teams out. A run that ends in an error, a timeout, or a wrong answer the user discards has consumed exactly the same tokens as a good one.
So reliability is a cost control, not just a quality measure. An agent that succeeds ninety percent of the time is not ten percent more expensive than a perfect one. It is more, because failures tend to be the long, looping runs that burn the most before giving up, and because users retry.
The same logic applies to ambiguity. Every question the agent cannot resolve becomes a maximum-length run.
Re-indexing, the quiet one
Embedding a document corpus once is cheap and everyone budgets for it. What gets missed:
- Changing your chunking strategy re-embeds everything.
- Changing embedding model re-embeds everything, and you cannot mix.
- A document management migration can re-embed everything by accident, because every file looks new.
We have seen a single weekend content migration cost more than three months of query traffic. Version your index and know what triggers a full rebuild before someone triggers one unknowingly.
Cheaper without being worse
Most of the savings are architectural rather than about picking a smaller model.
Cap and summarise conversation history. The most effective single change in most systems. Keep recent turns intact, summarise older ones, and stop resending the entire thread.
Retrieve less, but better. Teams reach for ten chunks because more feels safer. Better ranking with four chunks usually beats worse ranking with ten, and costs less. Measure it rather than assuming.
Route by difficulty. Not every step needs your best model. Classification, extraction and routing run perfectly well on a small one; save the expensive model for the reasoning that earns it.
Cache aggressively. Identical questions arrive far more often than people expect, especially for policy and documentation assistants.
Fail fast. Cap iterations and hand off to a human. An agent that gives up after four steps costs less than one that flails through fifteen and still cannot answer.
Fix the ambiguity upstream. If the same unclear question keeps producing long runs, better prompting of the user or a narrower entry point is cheaper than any model change.
Model it before you commit
Before building anything, work out four numbers: requests per day, model calls per request, tokens per call, and cost per token. Multiply. Then double it, because your first estimate of calls per request will be low.
Compare that to the fully loaded cost of the work being replaced, including the review time the agent will not remove. If the gap is not comfortable at ten times current volume, the design needs to change now rather than after launch.
Attribute cost per feature from day one. Not per subscription, per feature. When someone asks which part of the system is responsible for the bill, that answer should take a minute. Retrofitting it later is a week of work and an awkward meeting in between.
When the answer is not an agent
Sometimes the honest conclusion is that the economics do not work. A process that runs eleven times a month does not justify the build and the ongoing evaluation. A deterministic rule that gets it right every time beats a model that gets it right most of the time and costs money to run.
We would rather say that at the estimate stage than at the renewal. The same reasoning applies to low-code, which we have written about in when Power Automate is not enough.
We build agentic systems on Azure OpenAI and Semantic Kernel with cost attribution wired in from the start, and we will tell you when the numbers do not support it. See our AI agents and copilots service, or get in touch.