Uber’s CTO confirmed in May 2026 that his company burned through its entire annual AI budget in four months. 84 percent of its 5,000 engineers were using Claude Code monthly. 70 percent of committed code was AI-generated. 11 percent of backend updates were running with no human review.
The productivity gains were real. The budget model was wrong.
That story is the most useful reference point I have seen for business leaders thinking about deploying AI tools at scale. Not because Uber made a mistake — they did not. They made the right call and got real results. But the budget surprise reveals a mismatch between how enterprise software is traditionally priced and how AI tools are actually consumed that will catch businesses off guard if they do not account for it in advance.
This guide walks through how to build a business case and budget model for AI agent deployment that reflects how these tools actually work.
Start with the outcome, not the tool
Before you model a budget, you need to be clear about what you are trying to achieve. This sounds obvious but it is where most business cases go wrong.
The wrong starting point is “we want to implement AI agents.” That is a solution looking for a problem.
The right starting point is “we want to reduce the time our team spends on manual data entry from eight hours per week to under two hours” or “we want to handle after-hours customer inquiries without adding headcount.” Those are outcomes. You can measure whether you achieved them, and you can build a business case around the value of achieving them.
Write down three specific operational outcomes you want AI agents to produce. For each one, calculate what it is currently costing you in human time, error rates, or missed opportunities. That dollar figure is the value ceiling for your AI investment on that process. Your cost needs to be below it, and your margin of benefit above it needs to justify the implementation effort.
Understand how AI tools are actually priced
The Uber budget surprise came from treating AI tools like traditional enterprise software.
Traditional software licences are per-seat and predictable. You pay a flat fee per user per month. You know your maximum cost when you decide how many licences to buy. The cost is bounded by the number of seats.
AI tools are typically consumption-based. You pay for what the model processes, measured in tokens. The more your team uses the tool, the more complex the tasks they give it, the higher the bill. There is no per-seat ceiling.
This means that if your team adopts an AI tool more intensively than you planned — which is what happened at Uber, and which is likely to happen at your business too if the tool actually works — your costs can exceed your budget significantly without anyone doing anything wrong.
The practical implication is to build your budget model around usage intensity, not just user count. Ask: if every person who has access to this tool used it for two hours per day on average, what would that cost? What if they used it for four hours? What is the cost at the 90th percentile usage level rather than the average?
Most vendors can give you this data based on similar deployments. If they cannot, that is itself useful information.
Build a three-scenario budget model
For any AI agent deployment, model three scenarios before you commit resources.
Conservative scenario: Adoption is lower than expected. The tool gets used by 40 to 50 percent of the target user base, at moderate intensity. What is the cost, and what is the value delivered? Does this scenario still make business sense?
Base scenario: Adoption meets expectations. The tool gets used by 70 to 80 percent of target users at your expected intensity. This should match your central business case.
Aggressive scenario: Adoption exceeds expectations, which is what happened at Uber. The tool gets used by 90 percent or more of target users at high intensity. What is the cost? What is the value? And critically: does your business have budget flexibility to support this scenario if the tool works better than planned?
The goal of the aggressive scenario is not to scare you out of deploying. It is to make sure you have thought through the upside case. A tool that delivers 3x the expected value because adoption is 2x the expected level is a good problem to have — but only if you have the budget flexibility to let it run.
If your budget model only has headroom for the conservative scenario, you need either to add budget headroom or to implement usage controls that prevent the aggressive scenario from happening. Both are valid choices. Making them deliberately is the point.
Define what good looks like before you start
One of the most common reasons AI deployments fail to produce demonstrable ROI is that nobody defined what success looks like before the deployment started.
This is a discipline problem, not a technology problem. If you cannot articulate what the process looks like after the agent is running, and how that differs from how it looks now, you cannot measure whether the deployment worked.
For each process you are automating, document three things before you deploy.
The current state: how long does this process take per occurrence? How many times does it occur per week or month? What is the error rate? What does a mistake cost? What is the human time cost?
The target state: what should this process look like after the agent is running? What are acceptable accuracy levels? What human review, if any, will remain? What is the target cycle time?
The measurement plan: how will you check whether you hit the target state? Who is responsible for measuring it? When will you review it?
Those three documents are the minimum for a business case you can actually evaluate. Without them, you are running a deployment with no way to know whether it worked.
Govern usage actively, not retroactively
Uber’s budget problem was partly about usage governing itself faster than the budget model anticipated. When you put AI tools in front of people and the tools work, people use them. That is the desired behaviour. But if your cost model assumes lower usage, you end up with a budget surprise.
The solution is not to restrict adoption. That defeats the purpose. The solution is to monitor usage in real time and have a plan for what happens when usage hits specific thresholds.
Set a usage alert at 60 percent of your monthly budget allocation. When that alert fires, review whether the usage is producing commensurate value. If it is, the response is to adjust the budget upward for the following period. If it is not, the response is to investigate which usage patterns are not producing value and address those specifically.
This is not complicated governance. It is basic budget hygiene applied to a new category of spend. The same discipline you apply to cloud infrastructure costs, where you monitor usage and adjust allocation based on actual consumption, applies directly here.
Calculate value on output, not on cost reduction
The business case for AI agents is strongest when it is built on output value rather than cost reduction.
Cost reduction cases are weak because they invite scrutiny on every line item. Headcount reduction cases are politically fraught and often overestimated. And cost reduction framing systematically undervalues the benefit, because the most valuable thing AI agents often produce is not savings on existing processes — it is outputs that you were not producing before.
If your customer support team could only handle 200 inquiries per week before the agent, and the agent lets them handle 400 with the same headcount, the value is not just the efficiency gain. It is the 200 additional customers who got a response, the revenue protected by faster resolution, and the brand impact of consistently better response times.
Build your business case around what you can do with agent capacity that you could not do without it. That framing produces a more compelling case and a more accurate one.
What a good business case looks like
A one-page business case for an AI agent deployment should have:
A clear statement of the specific process being automated and the business outcome targeted.
The current state metrics: time, cost, error rate, volume.
The target state metrics: what the same process looks like after deployment.
A three-scenario cost model with a clear statement of budget headroom.
A value calculation based on output improvement, not just cost reduction.
A measurement plan with named owner and review date.
A timeline from decision to production deployment.
That is it. If your business case needs more than one page to make the argument, it is probably trying to justify something that does not have a clean value story.
Building a business case for AI deployment is part of what I cover in Omni Advisory sessions. If you want a structured framework for your specific situation, book a session and we will work through it together.