The cost of an AI agent is the cost of finished work

A cheap model call can create an expensive task

The token estimate is usually the easiest number in an agent proposal. It is also only a small part of the calculation the client needs. A workflow can make inexpensive model calls while consuming staff time through retries, review, corrections, and follow-up.

Consider a simple hypothetical comparison. One agent costs $0.20 in model and infrastructure usage per task, but one in five tasks needs five minutes of repair. If staff time is valued at $30 per hour, that repair adds an expected $0.50 per task. Another design costing $0.40 per task may be cheaper overall if it needs much less repair. These are illustrative figures, not market prices.

The unit to optimize is a successfully completed piece of work at an agreed quality level. For support, that might be a resolved case. For sales operations, it could be an accurately qualified lead with a usable record. Counting messages or tool calls tells you about activity, but not whether the expense produced value.

This also changes how a service provider should price and scope the engagement. A low monthly hosting allowance cannot compensate for an undefined maintenance burden. Both sides need to know which work is included and how exceptions will be handled.

More reasoning needs to earn its place

Complex architectures can be worthwhile when the task benefits from them. They can also add cost without improving the outcome that matters.

In its June 2025 account of a multi-agent research system, Anthropic reported that its agents used roughly four times the tokens of chat interactions, while multi-agent systems used about fifteen times as many. Those ratios describe Anthropic’s data and architecture, not a universal multiplier. They make the economic question concrete: the additional work has to produce enough value to justify it. [1]

For a narrow operational task, compare a direct workflow, a single agent, and a more elaborate design on the same cases. Include the time spent waiting on tools and reviewing the result. An architecture that produces a better explanation but the same business outcome may not justify a large increase in running cost.

Latency deserves its own budget. A customer waiting in chat experiences every serial dependency, even if the model responds quickly between calls. Measure time to useful progress and time to completion, including slow cases. An average can hide the customers who waited long enough to abandon the task.

Use larger reasoning budgets where they measurably improve decisions. Straightforward status lookups and difficult exception handling do not necessarily need the same path.

Perceived productivity needs an external check

People can feel more productive while taking longer, particularly when a tool makes the work more engaging or reduces unpleasant effort. That distinction matters when an agent project is justified through time savings.

METR’s early-2025 randomized study involved 16 experienced open-source developers completing 246 tasks. In that setting, access to the tested AI tools increased completion time by 19%, despite participants believing the tools helped. The study does not establish that AI coding tools generally reduce productivity. [2]

The later evidence also matters. In February 2026, METR explained that changes in who participated and which tasks were submitted made its follow-up estimates unreliable as a measure of current productivity. The researchers considered greater speedup plausible, but could not cleanly quantify it from that experiment. [3]

For businesses, the lesson is to measure the current workflow with the current tools. Record human attention separately from elapsed time, include review and repair, and compare tasks of similar difficulty. If an agent enables valuable work that previously was not attempted, capture that benefit separately rather than pretending it is a measured time saving.

A client pilot should therefore establish its baseline before the new workflow changes how work is selected. Otherwise, a convincing before-and-after story can be driven by a different mix of tasks.

Running costs include the bad days

Datadog’s April 2026 report, based on usage data from its customers, reported that around 5% of AI model requests failed, with capacity limits accounting for nearly 60% of those failures. These are request-level observations in Datadog’s sample, not agent task-failure rates. They nevertheless show why an operating-cost estimate needs room for infrastructure behaviour. [4]

Retries consume money and time. So do fallback models, duplicate work, and background checks. A provider should estimate these costs using observed runs, then examine how the estimate changes when volume grows or a dependency becomes unreliable.

Separate fixed costs from usage costs and staff work. That makes a commercial offer easier to understand and gives the client a basis for deciding whether to expand. Track unusually expensive runs so a loop or repeated tool failure does not disappear inside the monthly total.

Cost controls should preserve usefulness. A hard stop that abandons a customer halfway through an important action may save tokens while creating repair work. Prefer limits with a defined fallback and a record of what remains incomplete.

Build a cost model that understands outcomes

An R&D tool focused on these tradeoffs would replay representative tasks across different models and workflows, then compare verified completion, human repair time, latency, and total cost. Engineers and coding agents could optimize against that combined result rather than token spend alone.

Future products could detect loops, estimate the cost of a proposed workflow change, and identify cases where a cheaper path performs equally well. They could also show how costs change under realistic traffic and failure conditions.

The output should be understandable to the client: what it costs to complete this type of work, how often staff need to intervene, and which assumptions drive the estimate. That would make agent procurement less dependent on headline prices and give service providers a better basis for sustainable packages, maintenance terms, and expansion decisions.