Most AI agent proposals come with ROI numbers that do not survive contact with the finance team. They compare the cost of a build against a headline savings number that assumes perfect adoption, no supervision cost, and no ongoing maintenance. That is not a model, it is a wish.
This piece describes a practical framework for evaluating agent ROI before you build, in language a CFO will accept. It is deliberately conservative. If a project clears the bar described here, it is a real project. If it does not, walking away is the correct answer.
Start with the workflow, not the agent
Before modeling anything, write down the workflow the agent will absorb, in the same detail a new hire would need to do the job. If you cannot write it down, you do not understand it well enough to automate it, and any ROI number you produce is guessing about a process you have not defined.
For each step, note who does it today, how long it takes on average, how often it happens per week, and what the escalation path is when the step fails. That table is the foundation of the model. Every number that follows references it.
Number one: absorbed time
The first number is the loaded cost of the human hours the agent will absorb. Use loaded cost, not salary. Include benefits, tooling, management overhead, and the opportunity cost of the hours. If the person doing the work today is a senior operator whose next-best use is strategy work, use that opportunity cost, not their hourly rate.
Be conservative about how many of those hours the agent will actually absorb. First-version agents rarely absorb one hundred percent of the routine work they were built for. Pick an absorption percentage with your finance team as a planning assumption, model the resulting case, and treat the remainder as ongoing human capacity.
Number two: freed senior time
The second number is the value of the senior time freed up on the other side of the workflow. When a chief of staff agent absorbs inbox triage, the value is not the assistant hours saved. It is what the executive does with the reclaimed hours. If those hours go into strategy, hiring, or customer conversations, they are worth substantially more than the assistant hours.
This number is easy to inflate. Discipline it by asking what the senior person will concretely do differently, and whether they will actually reinvest the time rather than absorbing it as slack. If the honest answer is that the time will disappear into email at a different rate, do not count it.
Number three: added coverage
The third number is the value of coverage the agent adds where a human is currently a bottleneck. Support outside business hours, faster response to inbound leads, monitoring windows that used to depend on someone being awake. This is often the number that makes an agent worth building even when the first two are modest, because the coverage gap has a real business cost the current system quietly absorbs.
Quantify it against a specific outcome: reduced churn on tickets that go unanswered overnight, higher connect rates on leads contacted within an hour, incidents caught before they escalate. If you cannot tie the coverage to an outcome the business already measures, do not count it either.
Costs, honestly
Against those three benefit numbers, model three cost categories. Build cost is the one-time cost of the engagement, including integrations, evaluation setup, and initial supervision. Runtime cost is the ongoing model, infrastructure, and vendor cost per unit of work. Supervision cost is the human time required to review the agent's outputs, tune prompts, handle exceptions, and re-run evaluations when models or providers change.
Supervision cost is the number most models forget. Budget it as a meaningful share of the absorbed-time cost for the first year, using an assumption your finance team is willing to sign off on, and revisit annually. An agent with no supervision budget is an agent that quietly rots, and rot is more expensive than supervision.
Decision rules
With those numbers in place, set a decision rule before you look at the results. Pick a threshold with your finance team, for example a twelve-month net benefit that clears the build cost with a margin they consider defensible, using only benefit numbers they will accept. The specific ratio is a choice for the buyer's finance function, not a universal rule.
If the model clears that bar, build. If it does not, either narrow the scope until it does or walk away. Do not adjust the numbers to reach the answer you wanted. If the project cannot clear a conservative bar, it will not clear a real one either, and building anyway is how organizations end up with a portfolio of half-adopted AI initiatives nobody wants to defend at the next board meeting.
Where to start
The best first workflow to model is one that is repetitive, well-scoped, and currently absorbed by a person you would rather have doing something else. That combination clears the ROI bar more often than exotic use cases, and it produces a first-agent success the team can point to when scoping the next one.
If you want a second set of eyes on a model before you commit, our AI agents practice will review the assumptions and structure with you and tell you where they look thin. If the numbers do not hold up, we say so. That is the only kind of ROI conversation that is worth having.
Talk to the NU HAUS AI agents practice.
We consult on and build AI agents for corporate teams. Start with our AI agent consulting & development overview, or start a project.