Costing the Agent.

The shape of the cost, not the number

Deterministic cost is a function of volume. Requests multiplied by a rate, near enough, and the rate holds because the work holds.

Agent cost has a different shape. It is volume multiplied by a factor the organisation does not directly control: how many attempts a task takes, how much reasoning it triggers, how much context has to be carried through, how many tools get called before the work is done. Nothing bounds that factor from above except the guardrails somebody deliberately built.

Then a second term is added that has nothing to do with inference at all. It is the cost of the occasions when the agent was wrong.

The first term is metered and lands on a bill, so it gets attention. The second term is not metered and lands somewhere else in the organisation, usually inside a team that has no idea it is absorbing the cost of an automation programme. That is why it is routinely left out of the case entirely.

Cost per call is not a cost measure

This is where the finance question and the engineering question separate.

A call is a unit of machine activity. A completed task is a unit of business value. An agent can consume a great many of the first to produce one of the second, and the ratio between them is not constant across task types, across days, or across model versions. It moves when the prompt changes. It moves when a tool gets slower. It moves when the underlying model is updated by somebody who does not work for you.

Cost per call is stable, easy to obtain, and answers a question nobody actually has. Cost per correct, defensible outcome is unstable, harder to obtain, and is the only figure that can be honestly compared against the cost of the human process the agent is meant to replace.

Cost per call is not a cost measure. It is an activity measure wearing the clothes of one.

The line items an honest case has to carry

Inference metered per completed task. Meter the whole path a task travels, not the invocation. That total includes everything the agent did while failing, everything it did while recovering, and everything it re-read to keep its bearings. A task that succeeds on its first attempt and a task that succeeds on its fifth are the same outcome to the business and very different outcomes to the budget.

Retries and self-correction. Deterministic systems mostly fail loudly. Agent retries tend to succeed, which makes them invisible: the loop resolves, the dashboard shows green, and the true unit cost is being set quietly underneath. Model this as a distribution rather than an average. The average tells you what a normal day looks like. The tail tells you what the month costs, because a small share of pathological tasks can consume more than the entire well-behaved majority.

The human review path. Price it as a permanent line, not a transitional one. Reviewers, the tooling they work in, the time each review takes, the queue that forms when volume spikes, and the second reviewer that exists for the cases the first one escalates. Organisations habitually book this as a cost that decays to nothing once the system matures. It does not decay to nothing. As confidence rises the reviewers get reassigned, and the path is then unavailable at precisely the moment something goes wrong and it is needed most. In a regulated deployment the point is sharper still, because review is not a concession to immaturity. It is a control, and controls do not get retired because the thing they control has been behaving.

Latency as an experience cost. Latency is normally filed as an engineering concern, and it is also a financial one. An agent slow enough to break a person's attention costs the throughput of the person waiting on it. In a customer-facing path it costs abandonment. In an internal path it costs the worst outcome available, which is a workforce that quietly routes around the system and keeps the old process alive in parallel. Now the organisation is paying for both.

Errors weighted by reversibility. Two mistakes of identical technical severity carry wildly different costs depending on whether they can be taken back. A weak draft that a person rewrites is close to free. A wrong message sent to a customer, a wrong entry written into a system of record, a wrong payment released, a wrong eligibility decision communicated as final: these are not more expensive because the model was more wrong. They are more expensive because the action was irreversible. The price of an error is set by the reversibility of what the agent was permitted to do, which means the error budget is decided at design time by whoever chose the permissions, not at runtime by the model.

Evaluation and monitoring as running cost. Evaluation sets are built once and maintained forever. Every model update, every prompt revision, every new tool and every drift in the incoming data changes what the system does, and none of those changes announce themselves. The suite that detects the change has to be curated, re-run and extended by people who understand the domain well enough to say what a correct answer looks like. That is a standing operating expense with a headcount attached. Booking it as a one-off project cost is the most common structural error in these cases, and it is the one that turns a positive business case negative in the second year.

The evidence a regulated deployment must produce. Capture at decision time is cheap. Reconstruction under examination is not. Recording which policy version was in force, which controls fired, who owned the decision and what the agent actually did costs a modest amount of engineering while the system is being built, and an enormous amount of senior time when it was not built and somebody now needs the answer. Evidence has to exist at the moment of the decision, so this line item is unusual: it can only be paid early, and paying it late is not the same purchase.

What changes when the unit changes

Change the unit and the engineering changes, which is the practical reason any of this matters.

A team costed per call optimises the call. Shorter prompts, smaller models, tighter context, fewer tokens on the wire. Every one of those moves looks like a saving on the chart the team is being measured against.

A team costed per correct, defensible outcome optimises the path instead. Fewer retries. Earlier refusal when the task is out of scope. Better routing, so that hard work goes to capable models and routine work does not. Narrower permissions, so an error stays reversible. Cheaper review, because the output arrives with its evidence attached rather than requiring a reviewer to reconstruct it.

The second set of decisions lowers cost per call as a by-product. The first set frequently raises the true cost of the system, because the money saved on each attempt is repaid with interest in the number of attempts required, in the reviews they generate, and in the errors that reach the world.

An agent that is cheap per call and expensive per outcome is the most common failure in this category. It is also the hardest to see, because it looks like success on the only chart most organisations have thought to build.

© 2026 Nabeel Khan. Costing the Agent is published under CC BY-NC-ND 4.0. Quote it, cite it, do not repackage it.