The demo costs almost nothing
Every AI agent looks cheap in the first week. Someone wires a model to a few tools, points it at a support inbox or a reconciliation queue, and it works on the first twenty examples. The bill for that week is small enough to ignore, so the business case writes itself: look how little it costs, look how much time it saves.
Then the agent meets real volume, real mess and real accountability, and the cost curve stops resembling the demo. The model invoice is still there, but it is rarely the largest line. This piece is about the lines that tend to be missed.
The model bill is the visible part
Start with the obvious cost, because it is easy to underestimate even that. An agent is not one model call. It is a loop: read the task, decide on a tool, call it, read the result, decide again. Each pass sends the growing conversation back to the model, so a task that takes eight steps costs far more than eight times a single call.
Three things drive this more than the choice of model:
- Context length. Long documents, full email threads and verbose tool outputs get re-read on every step. Trimming what the agent sees is usually the cheapest saving available.
- Retries and dead ends. An agent that wanders, calls the wrong tool and recovers is paying for the wandering. Tasks with a clear path cost less than open ended ones.
- Model tier. Using the most capable model for every step, including trivial ones like classifying a message, is a habit worth breaking. Many teams route simple steps to smaller models and keep the expensive one for judgement.
The cost nobody budgets: checking the work
An agent that is right most of the time is not the same as an agent you can trust. The gap between those two is filled with people.
Someone has to review the outputs, at least at first. Someone has to read the cases where the agent was confidently wrong. Someone has to decide which categories of task are safe to run unattended and which always need a human to approve. This review work is real labour, and it does not disappear when the agent improves. It changes shape, from checking everything to sampling, and from sampling to investigating exceptions.
Picture a finance team that lets an agent draft vendor payment queries. If a wrong reply simply wastes a vendor's afternoon, light sampling is enough. If a wrong reply releases money, every output needs approval, and the time saved shrinks quickly. The same technology, with a very different cost profile, depending on what an error does.
So the first honest question in any agent business case is: what happens when it is wrong, and who catches it?
Integration and upkeep
Agents act through tools, and tools are other people's systems. Each one is an integration that has to be built, secured, permissioned and maintained.
This is where agent projects quietly consume engineering time. An API changes a field name. A login method expires. A downstream system gets slow and the agent starts timing out mid task, leaving work half done. None of this is exotic, but all of it needs an owner.
Permissions deserve particular care. An agent that can read a ledger and also write to it carries a different risk from one that can only read. We prefer to give agents the narrowest access that lets them do the job, and to make every action they take leave a record a human can follow. That design work costs time up front and saves a great deal of argument later.
There is also the prompt and workflow itself. Instructions drift out of date as policies change. Edge cases accumulate. A system that nobody tunes slowly gets worse relative to the business around it, so budget for ongoing maintenance, not a one time build.
Evaluation is a cost, and skipping it is a bigger one
You cannot improve what you cannot measure, and agents are hard to measure. The same input can produce different outputs. A change that helps one kind of task can quietly hurt another.
The fix is a test set: a collection of real, representative tasks with known good outcomes, that you run whenever you change the model, the prompt or a tool. Building it takes effort, because someone must collect the examples and agree what good looks like. But without it, every change is a gamble, and the team ends up afraid to touch a system that is supposedly saving them time.
Evaluation also gives you the number that matters most: how often the agent does the whole job correctly, end to end. Not how often it sounds plausible. That figure, measured on your own data, is the real basis for any decision about autonomy.
Failure, exposure and the long tail
Some costs only show up on a bad day. An agent can be tricked by text hidden in a document it reads. It can make a confident mistake at volume, repeating it a few hundred times before anyone notices. It can expose information to a person who should not see it.
None of these are reasons to avoid agents. They are reasons to put limits around them: spending caps, rate limits, approval steps for irreversible actions, and a way to switch the whole thing off quickly. These controls are cheap to design in and expensive to retrofit after an incident.
A better way to count
Instead of asking what the agent costs to run, ask what a completed task costs, end to end. Add model usage, review time, integration upkeep, evaluation effort and a sensible allowance for exceptions. Divide by the number of tasks done correctly, not the number attempted.
Compare that figure with what the same task costs today. Sometimes the agent wins easily. Sometimes the answer is that a plain script, or a better form, does the job for a tenth of the effort. Both are useful findings.
A good first move is to run the agent in shadow mode for a few weeks: let it do the work alongside your people, compare results, and record what it costs. You will have a real number by the end of it, which beats a hopeful one.