The next economic question
Demand no longer waits for a person
Part I examined a familiar corporate response to a visible meter: organizations learn to optimize the unit, then shift their attention toward what the technology produces. AI adds a complication. Software itself can now consume the meter.
A human request has a natural cadence. Someone decides to act, supplies context, waits for a result and chooses what happens next. An automated workflow can call a model, invoke a tool, query a system and trigger another workflow without waiting for another person to type the next prompt. Compute budgets, rate limits and policy still create boundaries, but human attention no longer paces every unit of demand.
Consider an illustrative customer inquiry. A workflow might retrieve account context, ask a model to interpret the request, draft a response and prepare an update for another system. A permitted action may then initiate follow-up work. The inquiry is one business event; the activity it generates is a chain of machine interactions. This is a possible mechanism, not a claim that every workflow follows that sequence or operates without human approval.
The next cycle need not wait for another prompt
Human-paced
A person decides when to start the next cycle.
- Request
- Result
- Human judgment
- Next request
Software-paced
A permitted event or action can initiate further work.
- Business event
- Workflow
- Permitted action
- Further activity
Conceptual comparison. Human approval may remain in either workflow. Permissions, budgets and capacity still bound demand.
This changes the forecasting problem. The relevant demand unit is no longer only the number of users or prompts. It is the number of machine interactions a business event can initiate, how often that event occurs and how readily one interaction creates the next.
A forecast built around employee headcount can miss that change. The same team may support more automated workflows, run them more frequently or allow each one to do more work. Demand can expand without a corresponding increase in the people initiating it. The budget therefore needs an account of the activity the organization is choosing to enable.
The rebound question
A cheaper unit can produce a larger bill
Falling unit cost does not necessarily reduce aggregate spend. It may make previously marginal activity economical: more workflows, more frequent execution and more model calls within each workflow. A Jevons-style rebound is a useful lens, not a prediction that every efficiency gain will be consumed. The practical point is narrower: a unit-cost forecast cannot stand in for a demand forecast.
Two decisions are easily collapsed into one. The first is how efficiently a given workload can be delivered. The second is how much work becomes worth doing at that lower cost. An organization can improve the first and deliberately expand the second. A larger bill may reflect successful adoption rather than failed cost management.
Lower cost per case. Higher weekly spend.
Illustrative scenario, not client results or an industry benchmark. Pilot → rollout: 1,000 → 3,000 cases/week; model usage $200 → $300; human review $500 → $1,500; systems and controls $300 → $500. Review rate 10%, six minutes per reviewed case, $50/hour. All 30 rollout review hours are staffed here. Rollout investment is excluded; no outcome value is specified, so this is not an ROI finding.
Scale is already consequential. Google reported 3.2 quadrillion tokens per month across its surfaces in June 2026, compared with 9.7 trillion two years earlier. AT&T separately reported an average of 45 billion tokens per day in July. These measures establish magnitude, not causation. Their scopes are not comparable, and neither establishes that lower prices caused the growth or predicts another enterprise’s consumption.
For finance, a lower rate per token may coexist with higher total spend and still represent successful adoption. The economic question is whether the additional activity produces sufficient value after infrastructure, oversight and exception handling are included. Favorable unit economics and unfavorable aggregate economics can occupy the same dashboard.
The operating constraint
The workload can outgrow the way it is delivered
The inference bill is only one part of the calculation. If additional activity creates more review, exceptions or downstream system work, the operating burden may move while the model becomes cheaper. That is where the plumbing begins to matter: a workflow’s ability to generate work can exceed the organization’s capacity to complete it dependably.
The economics example assumes the organization pays for all the review the rollout requires. Hold the existing review team fixed instead, and the same demand becomes a capacity question.
The model can do more. The review team has a limit.
Illustrative scenario, not observed demand or a measured backlog. Same workload as Exhibit 2, but with existing review capacity fixed at 20 hours/week. Demand = cases × 10% review × 6 minutes ÷ 60. The 3,000-case rollout requires 30 hours, leaving 10 hours unmet. The threshold holds only while review effort and capacity remain unchanged. Exhibit 2 instead assumes all 30 hours are staffed and paid for.
The response is a management choice. Add capacity, change the scope of automation, or establish that a different review policy can still deliver the intended outcome. A cheaper model does not make that choice disappear. It changes how much work reaches the decision.
The SMS precedent
Cheap automation changes what management has to manage
Text messaging offers a useful management analogy. Software sends authentication codes, order updates and appointment reminders through the same utility that can carry unwanted traffic. Price per message is insufficient to decide who should send, what recipients have agreed to receive and which activity should be delivered or stopped.
Mobile operators and messaging providers developed the 10DLC registration ecosystem around sender identity and declared campaigns; CTIA’s voluntary practices address consent and consumer choice. AI will not reproduce that architecture. The relevant lesson is that control becomes part of making cheap capacity usable.
The plumbing is not merely a brake on adoption. Well-designed controls make more automation economically usable: they define what software may do, contain exceptions and preserve accountability as activity grows. The strategic question is which boundaries should expand with demand—and which should remain deliberate.
The next decision
Scaling workload is not delegating authority
Expanding the volume of an existing task and delegating a new decision are separate choices. Producing more drafts under the same approval boundary changes workload. Allowing software to approve a financial action changes authority. Evidence that the first can scale does not, by itself, establish readiness for the second.
More throughput. More authority?
| Workflow step | Same permission | New delegation |
|---|---|---|
| Draft response | Model | Model |
| Approve refund | Human | ModelNew authority |
| Execute refund | System | System |
Conceptual example, not a quantified risk estimate. Human approval is the starting assumption here, not a universal requirement. Throughput evidence alone does not establish readiness for delegation; that depends on the decision’s scope and consequences.
Part II’s question is whether the operating model can support the work we choose to automate. Part III asks what the meter cannot tell us about that work: how outcomes vary, how consequential a failure can be, and what authority we are prepared to delegate.