Most AI agent ROI conversations get stuck at the wrong level: "is this thing smart" instead of "is this thing worth what it costs." The second question has a real answer, and it's the more useful one, because it determines whether an engagement gets funded past a pilot.

The formula, and why it's simpler than people expect

ROI (%) = [(Total Benefits − Total Costs) / Total Costs] × 100. The formula isn't the hard part. Correctly identifying what belongs on each side of it is.

What actually belongs in "total costs"

The most common mistake we see is a cost model that only includes the initial build and the per-token API price. It leaves out ongoing monitoring, the inevitable post-launch tuning period, and the human time spent reviewing the agent's output, all of which show up whether or not they were budgeted.

What actually belongs in "total benefits"

A two-tier measurement approach that actually works

Measuring everything at once from day one tends to produce noisy, unconvincing numbers. A tiered approach gets you a defensible number faster.

Tier 1: immediate, mechanical comparison

Compare the AI system's cost per resolved interaction against the human cost per interaction, then multiply by volume. This is the number you can calculate almost immediately after launch, and it's the one that answers the first question anyone funding the project will ask.

Tier 2: medium-term quality and downstream impact

Track first-contact resolution rate, satisfaction score changes, and escalation rate reduction over weeks, not days. This tier tells you whether the system is working well, not just working cheaply. A system that's cheap but produces worse outcomes isn't delivering ROI; it's just moving the cost somewhere less visible.

A number worth having before you start
Establish your baseline before deployment, not after: cost per interaction, average handling time, error rate, and escalation rate for the specific workflow you're automating. Without a real baseline, any post-launch number is a guess dressed up as a metric.

What "good" actually looks like

Benchmarks vary enormously by use case, so we're deliberately not citing a target percentage or payback window here. Any number precise enough to sound useful would imply more consistency across very different use cases than actually exists. What's more useful is this: a strong result clearly outweighs the full cost of building, running, and maintaining the system (not just the visible line-item savings), within a payback window short enough to feel low-risk for your business. Sanity-check your own calculated number against your actual costs and outcomes, not against an external benchmark that may not reflect your use case.

Why the naive estimate usually runs low

We've written before about why the naive cost estimate for an AI agent tends to undercount, mostly from tool calls, retries, and context growth that a single-call estimate misses. The same undercounting happens on the benefit side of ROI: teams often measure only the most visible win (time saved on the task itself) and miss downstream effects, like faster resolution unblocking a queue elsewhere, that are harder to attribute but just as real.

How we approach this

We build the baseline measurement and the ROI model into discovery, before committing to an architecture, so the business case is grounded in your actual numbers, not an industry average that may not reflect what you're automating.