Stop Counting Tokens. Start Measuring Value.

An internal knowledge agent might burn through only a few hundred dollars of technology each month. It might still need a specialist to maintain its sources, investigate inconsistent answers, adjust instructions, and support users. Employees might spend extra time validating what it produces. The invoice is small. That doesn’t mean the capability is actually cheap, or that the work has gotten any better.

The opposite can be true for a system that continuously evaluates a large project portfolio. Its model and platform costs might look substantial, and those costs can still be economically minor if it helps leaders spot a material dependency or a deteriorating investment early enough to actually change course. The real difference between these two cases isn’t the price of intelligence. It’s what the complete capability costs, and what changes because it exists.

Run laid out the responsibility that kicks in once people start relying on an intelligent capability. Cost asks whether that commitment is actually worth it economically. Licenses, credits, tokens, transactions, model calls, they all still matter, but their precision can create a false sense of clarity. They tell the organization what it’s consuming, not whether the value created justifies the whole investment.

A production capability has a total cost of operation

A meaningful capability can require design, integration, security review, behavioral testing, knowledge maintenance, monitoring, user support, enablement, governance, and ongoing change. Higher-consequence uses may also need sustained human review or tougher evaluation. None of that is some incidental cost sitting around the real technology. It’s part of what it actually takes to make that technology dependable in the work it supports.

Not every interaction deserves a fully loaded accounting model. Calculating a total cost of operation every time someone uses an assistant to summarize a meeting would create more busywork than insight. But once leaders are deciding whether to build, scale, and sustain a material capability, visible consumption stops being enough. They need to understand what the organization is committing to operate, not just what it’s buying.

Architecture is part of that commitment too. A low-priced model connected through fragile, bespoke integrations can rack up substantial maintenance and support costs. A platform with higher licensing fees might actually be cheaper to sustain if it comes with governed identity, reusable connections, and established operational controls. Cheap intelligence doesn’t automatically add up to a cheap capability.

Released capacity needs a destination

Time savings are a familiar starting point for an AI business case. An activity takes an hour today and fifteen minutes with AI. Multiply the difference across employees, convert it into labor dollars, and there’s your number. That calculation can indicate the scale of an opportunity, but it turns misleading the moment every released hour gets presented as realized financial value. The activity got faster. That doesn’t mean the organization actually captured the difference.

Value is a lot more visible when the organization avoids external spending, absorbs growth without hiring to match, serves more customers, or gets more work done with the same headcount. Less administrative burden is worthwhile too, but it’s a different benefit than an actual reduction in spend. If the freed-up time just gets refilled with meetings, email, and coordination, the financial return can stay small even though the technology is working exactly as designed.

Released capacity needs a specific destination, spelled out ahead of time. A finance team that spends less time assembling an operating review might use the difference to investigate variance, sharpen forecasting, or advise leaders. A service team might handle more volume without sacrificing quality, while a manager might spend more time coaching and resolving hard issues. The business case should describe that intended change rather than just assume saved minutes will convert themselves into value on their own.

Value does not follow one productivity formula

Organizations distort AI economics the moment they force every investment into an hourly-savings calculation. Some capabilities just reduce effort while keeping the existing outcome the same. Others increase throughput, improve consistency, reduce error, or make service easier to scale. Still others improve the timing or quality of a decision, catch risk earlier, or make a form of work practical that human effort alone could never sustain.

These mechanisms have very different value ceilings. Leaders might spend weeks assembling information for a portfolio review and only a few hours actually deciding which programs to fund, stop, or accelerate. A capability that synthesizes performance, dependencies, commitments, and emerging risks can save preparation time, sure. But its bigger contribution might be changing one important decision before more capital or executive attention gets committed.

The same distinction shows up in customer retention, workforce planning, supplier management, and operational risk. Catching something earlier creates a chance to intervene while the outcome can still change. A capability can save almost no labor at all and still be valuable, simply because the organization noticed something it would otherwise have missed. A business case built only around visible activity will undervalue that contribution.

Decision benefits are genuinely harder to attribute than saved minutes, and leadership shouldn’t disguise that uncertainty with invented precision. The standard here is a credible explanation of what changed in the work, why it matters, what evidence would show improvement, and which economic outcome should follow. Harder to measure calls for better evidence, not for cutting decision value out of the investment case altogether.

Measure the change before monetizing it

Not every benefit needs to turn into a dollar figure on day one. Demanding a fully quantified short-term return before any experiment can move forward tilts everything toward simple efficiency uses over opportunities whose value just takes longer to show up. The easiest things to measure end up winning, whether or not they’re the things that actually matter most. That’s a measurement bias, not necessarily sound investment discipline.

A more useful approach separates evidence that the work is changing from evidence that the change actually produced economic value. A workforce-planning capability might first show that material skill gaps get identified earlier and that leaders act on that evidence more consistently. Longer-term outcomes might show up later in hiring cost, contractor use, delivery performance, or the ability to pursue new work. The first set of measures tests whether the intended operational change is happening. The later ones test whether it creates the expected value.

An experiment doesn’t need to claim perfect causality. It does need a credible connection between the observed change and the benefit expected to follow it. That’s more rigorous than presenting speculative returns as certainty, and more useful than refusing to invest in anything that can’t be monetized immediately.

Adoption is evidence, not proof of value

AI platforms make activity easy to count. Leaders can see how many employees use a tool, how often an agent gets invoked, how many summaries or other outputs it produces. Those measures help explain reach, enablement, and behavior change. They don’t establish whether the underlying work actually got better.

A widely used assistant might create modest value simply because it’s convenient. A specialist capability used by only twenty leaders might influence decisions of much greater economic consequence. Low usage can signal weak design or weak adoption, sure, but it can just as easily reflect work that’s important and infrequent. Activity only becomes meaningful once you interpret it against the actual purpose of the capability.

Usage should sit right alongside measures of the actual work. A preparation capability should show reduced preparation effort. A risk capability should show whether material signals arrive sooner and whether people act on them. A consistency initiative should show whether variation actually declines. Adoption tells you people reached the capability. It doesn’t tell you the organization got the intended result.

Optimize the complete capability, not the model invoice

Model consumption is worth managing, no argument there. Routing simpler work to smaller models, cutting unnecessary calls, reusing suitable outputs, these are sensible engineering disciplines, especially at scale. There’s little value in throwing the most sophisticated model at a routine task that a simpler service can handle just fine. Cost discipline should improve the economics of the work. It shouldn’t become detached from it.

Minimizing the invoice turns counterproductive fast when a cheaper model needs substantially more human review, or a lower-priced platform creates integration and maintenance work that eats up more than the licensing difference saved. A bespoke implementation might dodge vendor fees while quietly racking up technical debt. And using an intelligent agent where a deterministic rule would’ve worked just fine can add cost without improving anything. The comparison has to include quality, oversight, operating effort, and the consequences of getting it wrong.

The real economic target is the lowest total cost of hitting the required business outcome at an acceptable level of quality and risk. That includes the model, the platform, the architecture, the human contribution, and the ongoing operating commitment. The cheapest component isn’t necessarily part of the cheapest dependable solution.

Match economic scrutiny to the investment

Different opportunities deserve different levels of economic scrutiny. Low-consequence personal productivity should stay easy to explore. Operational capabilities should demonstrate real changes in effort, throughput, quality, or service. Strategic intelligence investments may justify a more rigorous review, since investment and uncertainty are both bigger, but their value shouldn’t get forced into a time-saving formula when the actual objective is a better decision or a new capability.

The comparison also needs an honest baseline. The current operating model isn’t necessarily some stable, cost-free alternative. Service expectations, operating complexity, and available platform capabilities can all shift. Sticking with the status quo can carry real consequences for margin, growth, employee experience, or operating leverage. That’s not an argument for deploying AI out of fear. It’s a reason to compare the proposed change against the real alternative instead of an idealized one.

A healthy portfolio avoids both extremes. It doesn’t demand a five-year financial model for every experiment, and it doesn’t let consequential programs survive indefinitely just on the claim that AI is strategically important. Economic rigor should rise right along with investment, consequence, and uncertainty.

The business case should mature with the capability

An early experiment begins with a hypothesis: intelligence might improve this work enough to justify further learning. Measurement should establish whether the intended change is plausible, not manufacture a precise long-range return out of assumptions the organization can’t yet validate. The point of the initial investment is to learn enough to make the next decision more intelligently.

A pilot should produce better evidence about who benefits, what behavior changes, where the system fails, how much operating effort it actually requires, and whether the targeted outcome is starting to show up. As the capability enters production, actual costs replace estimates and the value case can get more demanding. Continued investment should reflect what the organization has learned, not the confidence of the original proposal.

That case should stay open through the whole lifecycle. Custom functionality might become standard within an enterprise platform. Another model might reduce cost. A redesigned process might change the value of the capability entirely. The right response might be to scale it, redesign it, replace it, or retire it. Cost isn’t a calculation you finish once at approval. It’s part of operating the asset responsibly.

Make the economic commitment explicit

Before committing to a material capability, leaders should be able to explain its complete cost, the operational change it’s intended to produce, and the evidence that would show improvement. Where time savings are part of the case, the intended use of released capacity should be spelled out. Adoption, technical performance, and change in the underlying work should stay distinct from each other, not get combined into one blanket claim of success.

The commitment should also define what would actually cause the organization to change course. Scaling, redesigning, replacing, and retiring are all legitimate investment decisions when the evidence supports them. A business case that can only justify the original approval is a lot less useful than one that helps leadership decide what to do next as costs, conditions, and results come into focus.

The unit of value is the work

The price of intelligence, and the capabilities bundled into enterprise platforms, will keep changing. A strategy anchored to a particular token price or credit schedule is a lot less durable than one grounded in the actual work being improved. The important question is whether intelligence releases capacity for valuable activity, improves a consequential decision, catches risk earlier, increases operating scale, or strengthens a capability the organization actually needs.

A cheap agent doing unnecessary work is still unnecessary. A more expensive capability that materially improves the right work can be an exceptional investment. Cost discipline means understanding the complete commitment, testing whether the intended value is showing up, and continuing only while that value justifies sustaining the capability. The unit of value was never the token, the prompt, or the agent. It’s the work that changes because intelligence is available.