A Playbook for Building a Real-Time AI FinOps Model at Scale

About the author: Drawing on several decades at the forefront of enterprise technology, Ken Yagen partners closely with Norwest’s investors and portfolio company leaders to define product strategy, activate AI inside their businesses and software, architect technology transformation, and shape talent strategy and organizational design. He also leads Norwest’s Kinetic program and serves as a trusted advisor to CEOs, CTOs, and product leaders.

Revenium, an AI FinOps platform, recently shared a story about two AI agents that got stuck talking to each other for 11 days. By the time someone noticed, the conversation had reportedly consumed $47,000 in compute. The agents were executing perfectly within their allocated parameters. So what happened?

They were built without financial guardrails.

It’s a slightly comical example, but the underlying issue is one I’m hearing more often as companies move from AI experimentation into production.

When running AI experiments, the primary goal is learning what the technology can do. As a result, the unit economics have been relatively easy to deprioritize. Teams may be working with fixed platform fees, bundled pricing, or credits that shift attention away from marginal compute costs. The cost of another prompt, model call or agentic workflow may not receive much scrutiny.

Now, organizations are facing growing pressure to shift from seat-based to API-based pricing, even for workloads that are still experimental. This changes the economics of AI development. Costs become directly tied to consumption, making it harder to separate experimentation from the financial considerations of running AI at scale.

The stakes increase further when AI systems move into production.

As employees and customers interact with AI systems at scale, workflows increasingly depend on orchestrating multiple models, agents, and tools. This includes agent-to-agent (A2A) interactions, where AI agents communicate and execute tasks with one another, sometimes creating extended loops like the one in the opening example.

Every token, model call, retry, and intermediate step contributes to the cost of delivering an outcome. At production scale, those costs can compound in ways that are difficult to predict, introducing new usage patterns, dependencies, and failure modes that teams may not yet know to look for. And then there are, of course, the unknown unknowns.

We can easily measure how many tokens a team or agent consumed and what we spent. But there’s a more pressing question, how did that AI investment translate into value for the business more broadly?

I’m convinced that answering this question requires a new FinOps model for AI at scale, one that provides real-time visibility into costs and applies financial guardrails and governance as AI workloads execute.

My background in systems engineering taught me to step back from any individual technology and look at the relationships between the different parts of a system. It’s the inputs, outputs, constraints, people, processes, and dependencies that determine how well everything performs together.

I find that lens is especially useful for AI. I think of tokens less as a utility expense and more as investment capital. That is, you would not allocate capital the same way across every part of a business. The same should be true of machine intelligence.

In the conversations I’m having with executives and boards, a lot of the AI metrics I’m seeing are still activity metrics: tokens consumed (i.e. tokenmaxxing), licenses activated, prompts submitted, pull requests generated, lines of code written. We used to call these vanity metrics. Today, I think of them as “AI theatre,” visible signs of activity that do not necessarily tell us whether the underlying system is creating value.

More output is not the same as more value, especially when the gain in one part of the workflow creates friction somewhere else.

For instance, an AI coding system can generate more pull requests than a human developer. But if that creates a larger queue for code review, we have simply accelerated one part of the system and moved the constraint somewhere else. The same dynamic can happen across product development, customer support, sales, or virtually any other AI-enabled workflow.

That is one of the failure modes I see repeatedly: teams can execute extremely well against the wrong constraint. AI makes one part of the system faster, but the organization has little to show for it because the consequential bottleneck sits somewhere else. In an enterprise, that might mean engineering ships faster while product, operations, or customer adoption becomes the limiting factor. In an AI-native startup, it might mean a team builds a technically impressive product without solving for reliability, differentiation, or sustainable unit economics. In both cases, the organization has increased activity without increasing business value.

A system can only move as fast as its constraints allow. This principle is central to the Theory of Constraints, popularized by Dr. Eliyahu Goldratt in his 1984 book, The Goal. Optimizing one step in isolation does not necessarily improve the performance of the whole.

A more useful starting point for AI economics is the cost per completed unit of value.

Take product development as an example. AI can help a product manager generate more requirements, prototypes, and specifications, while engineering can use it to produce more code, faster. Those activity metrics are useful to track, but customers ultimately care about the outcome.

One way to measure that outcome is to connect AI spending to the work being delivered. By linking AI usage costs to project tickets in systems like Jira or Linear, organizations can understand how much AI compute contributes to developing specific features, track delivery velocity, and evaluate costs against completed work.

For companies building custom software for clients, this level of visibility can also help attribute AI costs to individual customer projects and the features delivered within them.

A more meaningful measure is whether AI helps the organization move a validated idea into customers’ hands faster, with greater confidence that it solves a problem they care about.

AI can help create that confidence earlier in the process. A product manager can build a working prototype, put it in front of customers, learn from their response, and refine the idea before handing it to engineering.

That may require spending more tokens upfront. But if it reduces downstream rework and helps the team build something customers actually value, the overall return can be much higher.

To understand that return, organizations need to answer three questions:

There is no single measure of AI value that applies across every system. This makes it important to establish a flexible data model that connects AI usage and costs to completed jobs and business outcomes. With this foundation, organizations can define ROI metrics specific to their workflows while maintaining standardized views of efficiency, effectiveness, and economic return.

Customer support provides a useful example. Counting cases resolved is insufficient because speed, quality, and the level of human involvement also shape the value of the outcome. A customer who needs an issue solved within an hour receives little value from a resolution that arrives the following day. Measuring cost per successful resolution alongside time to resolution, customer satisfaction, and the percentage of cases resolved without human intervention provides a more complete picture of whether AI is improving performance and delivering a worthwhile return.

That same systems view changes how we think about efficiency. A step that appears more expensive in isolation may improve the economics of the overall workflow if it removes a downstream constraint, reduces rework, or increases the likelihood that the final output creates customer value.

One company in our growth equity portfolio is putting this approach into practice. The company’s Chief Product Officer is training a team of “Forward Deployed PMs” who work directly with customers to prototype and validate new features before involving engineering.

Using AI, these product managers can turn customer requests into working prototypes, gather feedback, and refine requirements earlier in the development process. This requires additional AI investment upfront but helps the organization avoid spending engineering resources on ideas that haven’t been validated.

The potential return comes from reducing downstream rework, making better decisions about which features to build, and getting valuable products into customers’ hands sooner.

Rather than measuring how many prototypes the team produces, the company can evaluate engineering effort avoided, rework after handoff, time from validated concept to production, and adoption of the resulting features.

Once the unit of value and the surrounding system are clear, the next step is making those relationships visible. Rather than simply minimizing the “I” in ROI, the goal is to both understand and forecast where additional investment can produce a greater return.

The aim is to create a clear line of sight from the resources being consumed, to the work those resources support, to the business value that work creates. By AI FinOps, I mean the operating discipline for making those relationships visible and measurable.

The architecture needs to connect three pieces of information:

At a minimum, teams should be able to trace AI usage to a specific department, user, customer, workflow, initiative, project, or feature, and then connect that consumption to the corresponding unit of value.

This requires a systems view of AI economics.

In production, cost reflects more than model usage alone. It also includes input, output, and cached tokens, context, intermediate agent steps, tool calls, retries, and the use of multiple models within the same workflow.

That broader system is often referred to as the AI harness. The harness sits around the underlying model or models and governs how intelligence is applied: what context is provided, which models are used for specific tasks, what tools and data sources are available, when additional agents are invoked, how workflows are validated, and how the system responds when it encounters uncertainty or failure.

This is also where AI FinOps needs to evolve beyond traditional cost monitoring. Rather than analyzing consumption after it occurs, organizations need real-time visibility into how AI resources are being used, with financial guardrails that can be enforced at runtime. That means using live usage and cost data to apply spending limits, control model selection, flag unexpected consumption, and pause or redirect workflows before costs escalate.

The goal is to make financial governance part of how AI systems operate, so teams can manage costs as they accumulate while maintaining visibility into the business outcomes those resources support.

Consider a customer usage analysis conducted by Revenium. The analysis identified several opportunities to improve AI cost efficiency, including reducing unnecessary context, optimizing caching, selecting less expensive models, and upgrading to more cost-efficient model versions.

One finding was particularly interesting: Revenium estimated potential savings of approximately $15,000 over 30 days from improving context efficiency, compared with $3,600 from changing model selection. Both estimates depended on maintaining output quality and task performance, and the opportunities overlapped, meaning the potential savings could not simply be added together. These were modeled opportunities valued at API rates, rather than demonstrated reductions in the customer’s bill. The comparison illustrates why organizations need visibility into how AI workloads actually operate, rather than focusing solely on token pricing.

Identifying potential savings is only the first step. Teams still need to determine whether changes affect the quality and cost of completed work. Does reducing context compromise output quality? Does switching models introduce additional retries or human review? When volume or complexity increases, does the optimization ultimately reduce the cost of a successful outcome?

By connecting AI consumption to specific workflows and completed units of value, organizations can evaluate these tradeoffs and make more informed decisions about where to optimize and invest.

An AI FinOps model becomes useful when it helps the organization make better decisions about where to spend, where to optimize, and where to invest more.

Many companies are moving beyond AI experimentation. They have distributed tools, encouraged teams to test new workflows, and started building AI into products and operations. The challenge now is figuring out how those practices should work once they become part of the business.

That does not mean putting tight controls around token usage too early. There is a learning curve to using AI well, and teams need enough room to discover which workflows actually create value. If leaders constrain usage before that learning happens, they risk optimizing away the experimentation that reveals where AI can create the most leverage.

One of the principles I can’t emphasize enough is to teach a mindset rather than a tool. Models, harnesses, and pricing structures will keep changing. The more durable capability is learning to step back and see the workflow as a system: where the inputs are coming from, where constraints are forming, how one decision affects another part of the process, and where additional investment can create leverage.

That systems mindset changes the FinOps conversation. Instead of asking only, “Which model costs less?” teams can ask, “What are we trying to accomplish, where is the constraint, and what combination of models, tools, and human judgment will produce the best outcome?”

From there, the visibility created by the FinOps architecture can support increasingly informed allocation decisions.

Some workflows may justify a more capable and expensive model because accuracy, reasoning quality, or speed materially affect the customer outcome. Others may perform just as well with a smaller model. In some cases, better context or a more efficient harness may matter more than model choice. And sometimes the right answer will be to spend more because the additional investment produces a larger improvement in the completed unit of value.

That is why I think of tokens less as a utility expense and more as investment capital. You would not allocate capital the same way across every part of a business. The same should be true of machine intelligence.

The objective is not to “peanut butter” AI across the organization and assume every team will become incrementally more productive. Different workflows, teams, and individuals will generate different returns. Leaders need to learn where AI creates leverage, where constraints are moving, and where additional investment is justified by the outcome.

The goal is to build an operating model that makes those choices explicit: where AI should be applied, what value it is expected to create, and how the organization will know whether the investment was worth it.

The larger shift here is that organizations are beginning to purchase something they have never been able to buy in this form before — intelligence.

That changes the economics of technology investment. Rather than another infrastructure expense to simply minimize, tokens are resources that can be directed toward solving problems, reducing uncertainty, accelerating work, and creating customer value.

Like any form of investment capital, tokens should not be allocated uniformly.

The right question is not whether one team used more tokens than another, or whether this quarter’s AI bill went up. It is where that investment is producing leverage. Are we resolving customer problems faster? Are we validating better ideas before we build them? Are we reducing rework? Are we getting valuable products into customers’ hands sooner?

Those answers will change as models improve, costs fall, new harnesses emerge, and the constraints inside organizations move. That is why the durable capability is not mastering a particular AI tool or optimizing a single cost line. It is developing the systems discipline to continuously understand where value is being created and where the next constraint has appeared.

AI FinOps establishes the framework to do exactly that.

The companies that benefit most from AI will be the ones that learn where machine intelligence is most valuable and direct investment accordingly.

To help executives better understand and manage their investments in AI, we’ve translated the principles explored in this article into an in-depth AI Investment Review Card. This practical framework helps leaders evaluate where AI resources are being spent, what business value they generate, and where additional investment may be justified.