An agent's business case is a cost per task, not an autonomy rate

Most agent proposals lead with a percentage: the share of cases the agent will handle without a person. It is an attractive number, it is easy to put on a slide, and it is the wrong one to fund against.

An agent that resolves most cases on its own and produces escalations nobody can act on quickly can cost more than the process it replaced. An agent that handles fewer cases unattended but turns every approval into a ten-second check can pay for itself comfortably. The difference is invisible in the autonomy rate and obvious in the cost of a finished task.

What a finished task actually costs

A task is finished when the outcome is right and nobody has to touch it again. Counting the cost of getting there means counting more than the model.

Compute and model usage. Visible, metered and easy to forecast. Rarely the place where the business case is won or lost.

Approval time. Anything irreversible — money leaving, a customer contacted, a commitment made — goes past a person. How long that confirmation takes, multiplied by volume, can easily be the largest line in the case, and it depends almost entirely on design.

Escalations. Cases the agent cannot settle come back to people. A good escalation arrives with the evidence gathered and a recommendation; a bad one arrives as a case somebody has to start from scratch, plus a log to read first.

Errors found later. The cost of being wrong depends on where it is discovered. A mistake caught at approval costs seconds. One found by a customer costs considerably more, in money and in trust. Where errors get caught is therefore a design decision, not a matter of luck.

Keeping it running. Tools and integrations kept working as the systems around them change, the evaluation set kept current, decision logs actually read. This is a standing cost, not a project cost, and somebody has to own it after the project team moves on. That person’s time belongs in the case.

Infographic

What one finished task really costs

1. 01Model and computeVisible on the invoice and the easiest layer to forecast.
2. 02Approval timeMinutes a person spends confirming each outbound action.
3. 03Escalation handlingCases handed back, and what they are handed back with.
4. 04Correcting errorsMistakes found later, including the ones a customer finds.
5. 05Keeping it runningTools, integrations and the evaluation set kept up with change.

Compare it with today, honestly

The other half of the case is the current cost of the same task: how long it takes, who does it, how often it is redone, and how long cases wait in a queue. If nobody knows this with any precision, measuring it for a few weeks before the build is worth doing for its own sake.

Then the comparison fits into a sentence anyone on a board can follow. Today a case costs this much and takes this long; with the agent, including approvals, escalations and corrections, it costs this much and takes this long; and here are the assumptions.

Include the queue. A case that waits two days for a person and minutes for an agent has a value that does not show up in handling time: a customer answered sooner, an invoice settled sooner, a supplier paid on time. If that is part of the argument, say so, and put an assumption next to it.

Who should agree the number

Three people should agree the case before anything is built: the process owner, whose team will approve actions and handle escalations; finance, who will hold the cost per task to account; and whoever owns the systems the agent will act on, because the tools depend on them. If any of the three is missing, the case gets argued again after go-live, when changing it is more expensive.

What a good outcome looks like

Not a rising autonomy rate on its own. A good first year looks more like this: the cost of a finished task falling, approval time per case short and stable, escalations that arrive ready to decide, an error rate that is measured rather than estimated, and a decision log that somebody actually reads. None of these measures needs special tooling. It needs somebody collecting them from the first day.

Autonomy follows from that. Bounds are widened one class of action at a time, when the evidence from the previous step supports it, and each widening is a decision with a named owner rather than a drift.

The trap worth avoiding

Approval that is slow becomes approval that is skipped. If confirming an action takes as long as doing it, people start confirming without reading, and the gate exists on paper only. A business case that does not budget for fast, well-designed review is pricing in a safeguard that will not hold.

The same goes for escalations. If nobody’s week has room for them, they queue, and the queue quietly becomes the new process.

How we approach it

In AI agents engineering cost and latency per task are part of the observability built from the start, approvals are designed so that checking is fast, and the bounds widen only as the evidence supports it.