Agent Payback by Function: Six Studies Say Under 6 Months, One Says 15

Seven published studies put a payback number on enterprise AI agents. Six of them say under six months, and between them they cover six different business functions. The seventh, built on 420 survey responses rather than four customer interviews, says 15 months. The pattern in agent payback data is not about function. It is about who paid for the study.

The short answer

There is no reliable median payback period for AI agents by function. The studies that publish one are vendor-commissioned models of a designed composite company, and they cluster under six months whatever the function. Independent buyer surveys report far weaker returns and give no function breakdown at all.

That is the finding. The rest of this post is the evidence behind it, and what to put in a business case instead.

What the seven published studies actually report

If you want a payback figure with a written methodology attached, one genre dominates. It is the Forrester Total Economic Impact study, and every one is paid for by the vendor whose product it measures.

That is not a secret. Each study says so on its cover. It does mean the public evidence base for agent payback is sponsored research, which is worth holding in mind before any of these numbers reaches a slide.

All seven are Forrester Consulting studies commissioned by the vendor named. ROI figures are three-year, risk-adjusted and in present value terms. Where payback is published as a band, the band is reproduced.

How a Total Economic Impact study is built

Forrester interviews a small number of customers the vendor introduces. It then builds a composite organisation that blends those customers into one modelled company, applies a risk adjustment to the benefits, and discounts three years of cash flows to present value.

The method is transparent and the assumptions are printed. It is still a model of an organisation that does not exist, populated by customers who agreed to speak about a product they chose to keep buying.

What "payback" means inside these models

Payback here is the month in which the composite's cumulative risk-adjusted benefits exceed its cumulative costs. It is not the month your finance team stops seeing a net outflow.

The difference matters. The composite's costs are licence fees, professional services and some internal labour. Your costs include a data integration project nobody scoped, and a quarter of people quietly working around the thing.

Why six different functions produce the same number

A payback figure has three inputs: the benefit, the cost, and the shape of the curve between them. In a commissioned model, all three are chosen rather than observed.

The composite is designed, not sampled

Look at the evidence base column above. Four interviews. Six interviews. Four again. These are not samples in any statistical sense, and Forrester does not claim they are.

A composite built from four references will reflect four deployments that went well enough for the customer to speak on record. Deployments that stalled are not in the room. That selection alone is enough to compress payback.

The 15-month outlier has the largest sample

The Microsoft study is interesting precisely because it breaks the pattern. It combines 8 interviews across 6 organisations with a survey of 420 people who had used the products, then models a composite with $2.5 billion of revenue and 10,000 employees.

Its answer is $44.5 million of three-year benefits against $20.2 million of costs, a net present value of $24.2 million, and 15 months to payback. Wider evidence, broader scope, longer payback. That relationship is the most useful signal in the table.

Nobody commissions a study that lands at 14 months

Here is the part worth saying plainly. A vendor pays for one of these studies to support a sales motion, and the sales motion needs the number to be short.

None of this requires anyone to lie. It requires only that studies which come back weak never get published, while studies that come back strong get a landing page and a press release. Publication bias needs no bad actors, and it explains a tight cluster better than any claim about functions does.

What buyers report when nobody is paying for the answer

Set the commissioned studies aside and look at survey work sold to buyers rather than sponsored by sellers. The picture changes shape completely.

Forrester surveyed over 1,400 global AI decision-makers for its January 2026 analysis. Only 13% reported a positive EBITDA impact, and fewer than a third could link AI contributions to P&L. In the same survey, nearly half expect payback within a year while only 14% commit to a three-year horizon.

Those two findings sit badly together. Buyers demand a payback window that almost nobody in the same sample has demonstrated. The expectation is a procurement policy, not a measurement, and the commissioned studies are calibrated to clear it.

Bain's Automation and AI Pathfinder Survey 2026, published on 1 June 2026 across 951 global companies, adds the operational version. Nearly 40% of companies that measured AI cost savings came in below 10%, against a target of 11% to 20%. Only 7% run fully autonomous agents in production, and 41% name data access and integration as the top barrier.

Notice what Bain does not report. There is no payback-by-function table in it, and no median payback month for agents.

The by-function table in circulation, and what sits under it

Search for agent payback by department and you meet a specific set of figures within two clicks. A 5.1-month median across functions. 4.1 months for customer service, 6.7 for marketing operations, 9.3 for engineering, 3.4 for sales development, 8.9 for finance and operations. They are usually credited to a Bain agentic AI benchmark, or to BCG and Forrester surveys.

I went looking for the primary source. Every result was another blog post, a statistics roundup or a vendor content page. None of the figures appears on bain.com, and Bain's published 2026 survey work reports different metrics entirely.

What the restatements disagree about

The tell is not that the number repeats. It is that the restatements contradict each other about what the number measures.

One page presents 5.1 months as the cross-function median. Another attributes the same 5.1 months to sales development and marketing automation agents specifically. A third reports a Forrester study of 287 deployments with a median payback of 7.3 months. Those cannot all be true, and six restatements of a figure are still one source at best.

My position is simple: none of those numbers belongs in a board deck. This is the same failure pattern as the widely quoted agent pilot failure rate, which traces to aggregators rather than to any survey. A precise decimal is a rhetorical device as often as it is a measurement.

Engineering, the one function with an independent measurement

There is exactly one function where somebody ran a controlled experiment and published the result without a vendor paying for it.

METR recruited 16 experienced open-source developers and randomised 246 real tasks in repositories they already maintained, using Cursor Pro with Claude 3.5 and 3.7 Sonnet. Before starting, the developers expected AI to speed them up by 24%. They took 19% longer with the tools allowed, and afterwards still believed AI had made them 20% faster.

Set that against the GitLab study above, which reports a 20% individual developer productivity gain worth $7.4 million over three years, plus 80% faster onboarding and a code migration compressed from eight months into two.

Two studies asking two different questions

Both results can hold at once, and reading them as a contradiction is the mistake.

METR measured expert maintainers doing familiar work in codebases they know intimately. That is where an agent has least context advantage and most review overhead. GitLab's benefits sit in onboarding, migration and security remediation, which are the unfamiliar, high-volume tasks where the trade runs the other way.

So stop asking whether agents help engineering. Ask which engineering work, because the sign of the effect flips inside one function. That distinction also separates a real tooling decision from a licence purchase, as the build versus buy comparison for coding agents sets out.

Where this argument is weakest

Three places, and the first would change the most if I am wrong.

Commissioned is not the same as wrong

Total Economic Impact studies publish their methodology, name their composite, state their discount rate and apply an explicit risk adjustment to benefits. That is more disclosure than almost any free industry survey offers.

The bias sits in which customers get interviewed and which studies reach publication, not in the arithmetic. A reader who discounts them entirely throws away the most detailed cost models available in public.

One trial is not a verdict on a function

METR is 16 developers, one tooling generation, and open-source repositories with unusually high review standards. METR says so itself, and warns against reading the result as evidence that AI fails developers generally.

Agent capability also moved between early 2025 and now. A 2026 rerun could land on the other side of zero, and I would not be surprised if it did.

The third weakness is mine. I could not find a primary source for the circulating by-function table, and that is not the same as proving none exists. A paywalled benchmark could carry those figures. What I can say is narrower: no public page I opened contains them with a methodology attached, and the pages repeating them disagree about what they measure.

How to build a payback number your CFO can check

The useful move is not to find a better benchmark. It is to build a small number you own, which beats a large number you borrowed.

Start with a unit of work that already carries a price in your business. Cost per support contact. Cost per invoice processed. Fully loaded cost per qualified meeting booked. If a function has no priced unit of work, it has no payback number either, and that is worth discovering before procurement rather than after.

The last row is the one finance teams ask about and the one no vendor study can answer, because a comparison against the next best use of the money is not a product benefit.

Record the baseline before the pilot starts, with a date on it. A baseline reconstructed afterwards gets reconstructed to fit, and the METR result shows how confidently people misremember their own throughput. The same discipline applies to the contract, where the clauses a CFO should require before signing an AI deal decide whether a disappointing month is renegotiable or simply invoiced.

Then price the thing properly. Agent pricing is usually consumption-shaped, so a model built on a flat licence assumption will be wrong by month nine. The conversation-by-conversation arithmetic behind Agentforce pricing shows how fast a per-unit rate compounds at real volumes. It is the small version of the question the hyperscalers face in the payback math behind 2026 AI capital spending, and the small version is the one you can answer.

Frequently asked questions

Where to start this week

Take the agent business case currently sitting in your pipeline and do two things to it.

First, find every payback figure in it and write the primary source next to each one, with the sample size and who paid for the study. Anything you cannot trace to a document you opened yourself comes out of the deck. On current evidence that removes most of the numbers, which is the point.

Second, write down the unit of work the agent is supposed to make cheaper, and today's price for one of them. If nobody in the room knows that price, you do not have a business case yet. You have a procurement request with a chart on it.

Related reading