In Part 1 of a two-part series on the economics of enterprise AI, Dr. Dave Ferrucci AI proposes a more useful economic unit than tokens.
By Dr. David Ferrucci, Chief Technology & AI Officer, Unqork
Most companies are still trying to understand enterprise AI spend through the wrong economic lens. They look at tokens, API calls, seats, licenses, and cloud bills. Those are useful technical meters, but they are not the right abstraction for understanding the economic impact of AI once it starts doing real work.
If a CFO were told they could increase the productivity of engineers, analysts, marketers, legal teams, or operations staff by 2x or 3x for an incremental $20 to $50 per hour of AI-enabled work, the conversation would not begin with panic over model costs. It would begin with a more practical question: how much productive capacity are we buying, what work is it being applied to, and what value is it producing?
That is why I think the enterprise AI cost discussion is often misframed. In many cases, this is less a cost problem than a spend-control problem. Companies are giving teams access to a new form of elastic digital labor without the management discipline they would normally apply to any other labor pool.
AI as Elastic Labor
When AI is answering questions or helping draft an email, output tokens usage may loosely reflect value. But as AI becomes more agentic — writing code, generating tests, reviewing documents, producing analysis, operating workflows, summarizing cases, drafting marketing content, or supporting customer operations — the better analogy is no longer token consumption. It is labor.
When a company opens AI broadly across the enterprise, it is doing something economically similar to giving every manager access to a pool of low-cost digital assistants. Depending on the work, the tools, the models, and the orchestration involved, those assistants may effectively cost $5, $20, $30, or more per active hour. That is an extraordinary opportunity, but it is also a financial-management problem.
A CFO would not normally tell every manager, “Hire as many contractors as you want, for any task, with no budget, no staffing plan, no utilization review, and no accountability for value.” But that is close to what can happen when AI access is treated as just another software entitlement.
The right response is not to restrict AI reflexively. Enterprises already know how to manage elastic labor. They approve contractor budgets, size capacity, assign it to teams, track utilization, review output, and cut back when the value is not there. AI should be managed with similar financial discipline.
Token Consumption Doesn’t Cut It
A token measures model consumption. It does not tell an executive what human effort was avoided, what output was produced, or what business value was created. As models increasingly use hidden reasoning, tool calls, retries, and internal processing to improve output quality, token consumption becomes even more opaque as a business control.
A more useful unit is something closer to the Active Agent Hour.
An Active Agent Hour is not simply wall-clock time or token usage. It is the measurable time during which an AI system is actively performing work toward a business outcome — generating, analyzing, testing, summarizing, reasoning, operating a workflow, or coordinating tasks — under human supervision, workflow control, or system orchestration.
It is not a perfect unit, but it is much closer to how executives already think about work. Tokens measure model activity. Active Agent Hours measure digital labor capacity. Business outcomes measure value.
That distinction matters because the real business question is not, “How many tokens did we use?” It is, “How much digital labor did we deploy, at what cost, against what human baseline, producing what measurable value?”
The Active Agent Hour
This becomes especially important in software development, where both the AI costs and the economic claims can be significant. If a senior engineer, architect, or business analyst costs $150 to $250 per hour, and AI can increase that person’s productive output by 2x or 3x for an incremental $20 to $50 per hour of AI-enabled work, the economics can be compelling.
But that framing only works if the AI labor is actually increasing useful output. The harder questions are how much human labor the AI offsets, how much agent time is consumed, how much supervision is required, how much rework is introduced, and whether the resulting work is maintainable, secure, compliant, and reusable.
The simple economic model is this: start with the cost of doing the work the old way, subtract the remaining human labor, the AI labor consumed, and the cost of supervision and rework. What remains is the net value created.
That is more useful than token accounting because it maps AI usage to the economic structure companies already understand: labor, productivity, utilization, cost centers, and output.
Consider a software project that would traditionally require ten people. If an AI-assisted model reduces the required human labor to four people, then the gross labor offset is six people’s worth of work. But that does not mean all of that offset becomes value. The remaining four people may be using AI agents continuously, or even driving more AI work than the apparent headcount reduction implies. The AI may, in effect, be doing overtime.
That is where the Active Agent Hour becomes useful. It separates three things that are too often blended together in AI discussions: the human labor avoided, the AI labor consumed, and the net value created after accounting for both.
AI Acceleration Is Not Automatic
The Active Agent Hour also forces discipline around acceleration claims. There is a broad belief that AI will make work two, five, or ten times faster. In some contexts, especially isolated tasks, prototypes, or early development work, that may be directionally true. But acceleration depends heavily on how the human uses the AI.
A strong manager can direct labor efficiently, break down work clearly, inspect output, avoid duplication, and reduce rework. A weak manager can create confusion, churn, and waste even with inexpensive labor. AI is no different.
In complex enterprise work, speed gains are harder to generalize. Requirements analysis, integration, governance, security, testing, ambiguity, rework, coordination, and long-term maintenance all reassert themselves. The initial acceleration may be real, but it may not scale linearly as the work becomes more complex.
For that reason, I would be careful about making speculative acceleration the primary basis for AI pricing or CFO justification. Acceleration is real value when it can be credibly measured. But the more defensible economic case is labor economics: what human work was avoided, what AI work was consumed, what useful output was produced, and what net value resulted.
This logic applies beyond software. In legal, marketing, customer service, finance, and operations, AI may reduce labor cost, increase output, accelerate cycle time, reduce rework, improve quality, or lower risk. But in each case, the question is not whether AI was used. The question is whether the AI capacity produced measurable economic leverage against a baseline.
That is why enterprise AI is better understood less like traditional software spend and more like a new layer of variable labor capacity inside the firm. AI is obviously not the same as human labor, but once AI performs work, consumes budget, substitutes for human effort, and changes the economics of delivery, it becomes difficult to manage it only through a software-metering lens.
The companies that get this right will not simply ask teams how much AI they used. They will ask how much digital labor was deployed, what process it supported, what human baseline it was measured against, what the effective cost per useful output was, and whether the allocation should be increased, maintained, or reduced.
What Happens as Complexity Grows?
For many functions, the Active Agent Hour may become a practical way to manage AI capacity, cost, and value. But in software development, there is an additional question that deserves special attention: what happens to the productivity of those Active Agent Hours as software complexity increases?
That is where the economics can get harder. If AI is simply generating more code into the same complexity model, it may accelerate the very sprawl that later reduces its own effectiveness. The next question, then, is not just how to measure AI labor. It is how to make that labor more productive as complexity and application volume increase.
That is the focus of Part 2: how generic AI coding gains may decay as complexity grows, and how reuse, governance, and component-based application patterns become essential for improving AI labor productivity over time. Making Active Agent Hours more efficient as complexity increases is what we are focused on with UnqorkAI.