AWS published a framework on October 7 for building the business case for agentic automation, and its worked example carries a lesson for any CFO reviewing an agent budget: a claims-triage process that frees $1.26 million of labor capacity should book about $630,000 if only half of that reaches the P&L. The gap between those two numbers is where most agent business cases will be judged this year.
What AWS actually proposed
The post, written for AI center of excellence leaders, argues that the standard justification for automation spending (hours saved times labor cost, minus build cost) was designed for rule-based tools like robotic process automation. According to AWS, that model assumes stable processes, so it ignores the cost of maintaining automation as processes change. It assumes rule-based tasks, so it has no line item for exceptions. It assumes the automated work is the whole job, so it never counts human oversight. And it treats a saved hour as banked value, when freed capacity often refills with backlog and never reaches the profit and loss statement.
AWS replaces it with what it calls the Agentic Value Model: four value pools plus one governing condition. The pools are time savings, exception handling, decision quality, and change resilience with maintenance economics. The condition is value realization, meaning every benefit needs a defined mechanism that converts an operational improvement into money, and an accountable owner. For released labor, AWS says that means either reducing spend or redirecting capacity to a named, measurable outcome.
The worked example, and the arithmetic behind it
AWS labels its figures illustrative. A claims-triage process handles 200,000 claims a year at about 12 minutes each, at $45 an hour fully loaded, for a base cost of roughly $1.8 million. Automating the routine 70 percent releases about 28,000 hours, or roughly $1.26 million of capacity, before counting the oversight time those claims still need.
AWS then makes the point that matters. Freed hours only become savings if the company employs fewer people or cuts contractor, overtime or outsourcing spend. If attrition and lower overtime capture half the released capacity, the case should carry about $630,000, not the full figure. If staff are redeployed instead, the value is what they now produce, and AWS says to count redeployed value or cash cost reduction for each released hour, never both.
The second pool uses the same discipline. Of the claims, 8 percent need correction, which is 16,000 claims. Taking a correction cost of 3.5 times the roughly $9 handling cost gives about $504,000 in annual correction exposure. AWS calls that a baseline, not agentic value. The value is the share the agent removes: a 40 percent reduction, adjusted by a 75 percent realization factor, yields a modeled benefit near $151,000.
Adding the two pools as AWS sizes them gives roughly $781,000 a year in modeled benefit, against the $1.26 million that a labor-only case would have shown. That sum is our arithmetic on AWS’s illustrative inputs, and it is still before the costs AWS tells readers to net out: implementation, agent runtime, integration, evaluation, oversight, governance and change management, plus losses from any new errors the agent introduces.
A second source points the same way
AWS leans on outside research for the reason these cases fail. It cites McKinsey’s finding that successful AI transformations follow a 1:3:5 pattern. McKinsey’s article on closing the agentic adoption gap says that for every dollar invested in agentic technology, organizations spend three on process redesign and five on capability building and adoption. McKinsey says most companies invert the formula, and AWS repeats the point. A business case that prices only the software and the saved hours is, on that evidence, missing most of the spend.
The adoption data on this site fits the pattern. In Deloitte’s agentic AI survey, 42 percent of respondents had tested or deployed agents, but only 15 percent reported scaled, orchestrated multi-agent adoption. AWS cites McKinsey research that puts the same shape in different words: nearly two-thirds of enterprises have experimented with agents, and fewer than 10 percent have scaled them to tangible value. Two firms, two methods, and the same gap between pilot and P&L.
What it means for the buying committee
For a CIO or chief AI officer, the practical change is in who signs the number. AWS assigns each value pool an owner: an operations lead for released capacity, a quality lead for exception and error cost, a domain owner for decision quality, an engineering lead for maintenance. A saved-hours figure with no owner is a forecast nobody has to defend.
For the CFO, the useful test is the realization factor. Ask for two columns in every agent proposal: capacity released and capacity converted to reduced spend or a named outcome. The distance between them is the credibility of the case. In AWS’s example it is half.
For vendor negotiations, the framework gives buyers a firmer footing. AWS tells readers to net agent runtime and oversight costs against benefits, and to book implementation cost in the year it is spent for multiyear programs, then discount yearly cash flows to net present value. Buyers who model it that way will push on usage-based pricing and evaluation tooling, because those lines now sit visibly in the case. Our earlier coverage of Cognizant’s 30,000-person Claude training is one example of the capability-building spend the McKinsey ratio describes.
How to use it on the next proposal
AWS adds a prioritization matrix with two axes, task complexity and decision risk. Low-complexity, low-risk work stays on RPA, since agents add cost there without adding value. High-complexity, low-risk work is the capacity play. High-complexity, high-risk work is the decision-quality play, with a human in the loop. Low-complexity, high-risk work calls for hardened controls rather than more reasoning.
AWS also recommends a stop rule: stage the investment with explicit break-even targets and predefined points to stop funding agents that underperform. For a committee reviewing three to five candidate workflows, that rule and the realization column are the two items to demand before approving any budget line.
One caution on provenance. The post is vendor guidance, and AWS ties the measurement step to its own Amazon Quick Automate service, which it says produces case-level execution data. The customer results it cites, from Kitsa, dLocal and Genpact, are self-reported, and AWS itself says none of them proves all four value pools. The framework stands apart from the product: the realization-factor discipline works on a spreadsheet, whichever platform runs the agents.
Source: AWS Machine Learning Blog
