Infrastructure and the Economics of Compute

Intelligence has a cost.

For most of enterprise history, that statement would have sounded strange.

Human intelligence entered the economic system primarily through labor.

Machine intelligence enters differently.

It is consumed.

The machine may reason again.

Every act of machine intelligence therefore creates infrastructure demand.

At small scale, this can look like another technology bill.

At AI Native scale, it becomes something more consequential.

Compute becomes a productive input to enterprise execution.

That changes the economics of the operating model.

Traditional enterprise software economics are relatively familiar.

The organization buys software.

It pays licenses.

Infrastructure supports the application.

Employees use it.

The cost is usually connected to:

• users
• seats
• transactions
• storage
• infrastructure capacity
• or contractual subscriptions.

Machine intelligence introduces another economic structure.

Consumption can vary with the complexity of the work itself.

A simple classification may require one inexpensive inference.

A difficult investigation may require:

• large context
• multiple reasoning cycles
• retrieval
• several tools
• specialist agents
• evaluations
• retries
• and a frontier model.

The two workflows may have the same number of users.

They do not have the same execution cost.

This is why traditional software metrics become incomplete.

The relevant unit begins to move from:

toward:

and ultimately:

cost per outcome.

Much of the public discussion about AI infrastructure has focused on training.

The largest models require enormous compute to create.

That remains consequential.

But enterprise operating economics are increasingly shaped by something else.

Inference.

Training creates capability.

Inference consumes it.

Training may happen periodically.

Inference happens whenever the operating system runs.

As AI becomes embedded in enterprise execution, inference therefore becomes persistent infrastructure demand.

This distinction is fundamental.

The enterprise is not simply buying intelligence once.

It is consuming intelligence continuously.

The infrastructure market is already moving in this direction.

McKinsey estimates that inference will overtake training as the dominant AI data center workload by 2030, representing more than half of AI compute and approximately 30 to 40 percent of total data center demand.

Its 2026 analysis of inference economics argues that the industry is moving toward cost per token and energy per token as important measures of AI infrastructure efficiency. The same analysis notes that while individual inference costs continue to decline, aggregate infrastructure demand is expanding rapidly as AI moves into more applications.

Deloitte reaches a similar conclusion in its 2026 technology infrastructure research. Persistent inference, especially agentic execution involving repeated model interactions, can create materially different infrastructure economics from earlier proof of concept deployments.

The implication for the enterprise is straightforward.

AI infrastructure economics will increasingly be determined not only by the models an organization trains.

They will be determined by how much machine intelligence its operating model consumes.

There is an apparent contradiction in AI economics.

Inference becomes cheaper.

Enterprise AI spending rises.

Both can be true.

When the cost of a useful resource falls, organizations often consume more of it.

The cost of one unit can fall while the number of units rises much faster.

This is the central economic tension of machine intelligence.

The enterprise therefore cannot rely on falling model prices to control its AI economics.

McKinsey's 2026 enterprise AI FinOps survey found that organizations moving from experimentation toward broader deployment saw AI spending increase nearly fourfold. Ninety-three percent of qualified respondents reported exceeding their AI budgets.

The same research found that token consumption for the same agentic task can vary by as much as thirty times depending on execution behavior.

This variance matters.

Traditional capacity planning assumes some relationship between workload and resource demand.

Agentic execution introduces greater nondeterminism.

The enterprise is therefore managing not only increasing demand.

It is managing variable demand generated by machine reasoning itself.

The economic problem of AI Native execution is not expensive tokens.

Tokens are only one meter.

The deeper problem is that the enterprise is introducing a new class of productive resource whose consumption can be determined partly by software making decisions during execution.

A human employee cannot spontaneously create ten additional employees because a task became difficult.

An agent can invoke ten additional agents.

A conventional application does not usually decide that it needs thirty times more infrastructure because one transaction appears complicated.

An agentic workflow can consume radically different amounts of intelligence depending on the path it takes.

This means resource consumption becomes partially endogenous to the execution system.

The machine decides how much machine work to request.

That is economically powerful.

It is also dangerous without control.

Tokens matter.

They are measurable.

Providers charge for them.

They provide a useful view into consumption.

But the token is not the enterprise outcome.

Optimizing tokens alone can therefore destroy value.

The enterprise needs a hierarchy of economic measurement.

The objective is not:

It is:

maximize economically valuable execution.

Model inference is only one component of machine execution cost.

A production agent may consume:

• model inference
• embedding services
• vector retrieval
• databases
• storage
• network traffic
• tool APIs
• third party services
• sandbox environments
• compute
• observability
• evaluation
• security controls
• orchestration
• human review
• human exception handling.

An enterprise measuring only model charges may materially underestimate the cost of the execution system.

The appropriate comparison is therefore not:

It is:

fully loaded machine execution cost versus the economic value of the workflow.

This becomes especially important when comparing machine execution with human work.

A machine workflow may appear cheaper because only model charges are counted.

A human workflow may appear expensive because compensation, management and overhead are visible.

The comparison must be symmetrical.

Human labor has familiar economics.

Machine capacity behaves differently.

But the infrastructure supporting it may require substantial fixed investment.

These differences mean that human and machine capacity should not be compared through hourly cost alone.

The relevant comparison is the economics of the complete execution design.

This is the economic extension of the Work Allocation Test established earlier in the operating model.

Capability determines what is possible.

Economics helps determine what should scale.

Historically, most business managers did not manage compute directly.

Technology organizations did.

Business leaders managed:

• revenue
• people
• operating expense
• capital
• inventory
• risk.

Cloud computing began changing this relationship by making infrastructure consumption more elastic.

AI takes it further.

When machine intelligence becomes part of business execution, compute consumption becomes connected directly to operational decisions.

Compute therefore moves closer to the operating P&L.

The business cannot treat it entirely as an invisible technology input.

Managers already make capacity decisions.

Machine execution adds another question.

How much machine capacity should this outcome receive?

The execution budget introduced in Chapter 08 becomes an economic instrument.

A workflow may have:

• a human labor budget
• a model budget
• a compute budget
• an external service budget
• an exception budget
• and an overall cost target.

The manager can then make tradeoffs across the complete execution system.

The correct answer cannot be determined from infrastructure cost alone.

It depends on the outcome.

This leads to a more useful economic metric.

Cost per outcome.

• For a customer service workflow: cost per resolved case.
• For software engineering: cost per accepted change.
• For procurement: cost per completed sourcing event.
• For finance: cost per reconciled account.
• For security: cost per investigated incident.
• For sales: cost per qualified opportunity.

The metric connects infrastructure consumption to productive output.

It also makes comparison possible.

All can be compared against the same outcome.

This is the economic unit of the AI Native workflow.

Outcome economics.

Current enterprise evidence increasingly points toward this shift.

McKinsey's 2026 work on agentic economics argues that per-token pricing is becoming insufficient as a measure of enterprise AI economics because the true cost depends on routing, orchestration, workflow design, agent behavior and the complete execution path.

Its research also emphasizes that organizations should evaluate agentic workflows against the fully loaded cost of the work and the value of the resulting outcome rather than optimizing model consumption in isolation.

This distinction becomes more important as agentic systems expand.

The same task can be executed through radically different architectures.

Each architecture creates a different cost and quality profile.

The economic decision is therefore architectural.

AI economics and AI architecture are becoming inseparable.

Architecture determines consumption.

The architecture creates the bill.

This is why AI cost management cannot be relegated to procurement after deployment.

Economic design must exist inside the execution architecture itself.

The enterprise therefore needs another feedback loop.

This makes economic adaptation part of the operating system.

The enterprise does not merely ask whether the agent works.

It asks whether the execution system deserves more resources.

AI infrastructure will become more efficient.

McKinsey's 2026 analysis estimates that combinations of model optimization and infrastructure innovation could reduce inference cost dramatically over time. Its analysis identifies model optimization, advanced packaging, specialized silicon and optical networking among the major levers improving inference economics.

That is important.

But it does not remove the economic problem.

It changes the frontier.

The enterprise therefore needs economic discipline even in a world of dramatically cheaper inference.

Perhaps especially then.

Because machine intelligence can become abundant before it becomes free.

And once intelligence becomes a continuously consumed operating resource, the enterprise must answer a harder infrastructure question.

Where should that resource come from?

The answer depends not only on technical capability.

It depends on economics, latency, resilience, security, sovereignty and strategic control.

The enterprise now needs a compute strategy.

The enterprise now needs a compute strategy.

For most enterprises, compute strategy historically belonged inside technology strategy.

AI Native execution changes the significance of those choices.

When machine intelligence becomes part of how the enterprise produces outcomes, compute infrastructure becomes part of productive capacity.

The enterprise is no longer deciding only where applications should run.

It is deciding where machine execution capacity should come from.

That decision affects:

• cost
• latency
• availability
• security
• data locality
• model choice
• scalability
• resilience
• regulatory exposure
• and strategic dependency.

Compute strategy therefore moves closer to operating strategy.

The AI Native enterprise is unlikely to run every workload through one infrastructure model.

Different execution requirements create different economics.

• Some workloads may use public model APIs.
• Some may use managed cloud model platforms.
• Some may use dedicated cloud capacity.
• Some may use smaller specialized models.
• Some may run inside private environments.
• Some may require edge execution.
• Some may use several providers.

The architecture becomes a portfolio.

The question is not:

It is:

Which execution environment provides the strongest combination of capability, economics and control for this workload?

A low volume workflow may be most economical through consumption based access.

There is little reason to reserve expensive capacity that remains idle.

A high volume predictable workload may behave differently.

At sufficient utilization, dedicated capacity may produce stronger economics.

The infrastructure decision therefore begins with the workload.

The architecture follows the workload.

Not ideology.

Chapter 08 established model routing as an execution capability.

Its economic importance now becomes clearer.

A workflow does not necessarily require one model.

Different steps may require different intelligence.

The runtime can therefore allocate intelligence dynamically.

This is more than model selection.

It is infrastructure allocation.

The system is deciding which scarce machine resource should be consumed for which piece of work.

Using the strongest available model everywhere is operationally simple.

It is also economically weak.

The objective is not to maximize intelligence per invocation.

It is to provide sufficient intelligence for the outcome.

A model that is materially more expensive but produces no meaningful improvement in the workflow is wasted capacity.

A model that is cheaper but causes repeated retries, human escalation or quality failure may also be economically weak.

The optimal model is therefore not necessarily the cheapest or strongest.

It is the model producing the strongest outcome economics inside the complete execution system.

This creates a routing hierarchy:

The execution architecture becomes a resource allocator.

Infrastructure cost is not the only economic variable.

Time matters.

Latency therefore has an economic value.

The relevant optimization is not simply:

It is:

cost, quality and time relative to the outcome.

This is why workload placement cannot be separated from business context.

The same infrastructure can be economically excellent for one workflow and unacceptable for another.

As AI moves into execution, model availability becomes operational availability.

If a recommendation system is unavailable, employees may work around it.

If an autonomous execution system is unavailable, the workflow itself may stop.

That changes resilience requirements.

The enterprise must determine:

• what happens if the preferred model fails
• what happens if a provider becomes unavailable
• what happens if a region fails
• what happens if rate limits are reached
• what happens if capacity becomes constrained
• what happens if model behavior changes unexpectedly.

The answer may be:

• retry
• route to another model
• route to another provider
• degrade to a simpler workflow
• invoke deterministic execution
• return work to humans
• pause execution.

The appropriate response depends on consequence.

But the response must exist.

Resilience does not require every workload to support every level.

It requires the failure path to match the consequence of interruption.

AI infrastructure decisions are often discussed through data residency.

Where is the data stored?

Machine execution introduces a broader question.

Where does reasoning occur?

A workflow may retrieve sensitive enterprise information.

The location and governance of execution therefore matter across the entire chain.

For regulated or strategically sensitive workloads, the enterprise may need greater control over:

• where models execute
• where context travels
• where memory persists
• where traces are stored
• which providers can access the execution environment.

Data architecture and compute architecture converge.

Sovereignty is often framed through national regulation.

That is only one dimension.

Enterprises may also require operational sovereignty.

• Can the organization move the workload?
• Can it change model providers?
• Can it preserve its execution history?
• Can it retain its agent definitions?
• Can it reproduce evaluations elsewhere?
• Can it continue operating if commercial terms change?
• Can it maintain critical execution if access to a provider disappears?

These questions concern strategic dependency.

An AI Native enterprise that embeds machine execution deeply into its operating model becomes more dependent on the infrastructure providing that intelligence.

The deeper the dependency, the more deliberate the architecture should become.

Model portability will become an operating resilience capability.

This does not mean every enterprise should avoid provider specific features.

The question is whether the enterprise understands where dependency has accumulated.

A low consequence productivity assistant can tolerate substantial provider dependence.

A machine execution system responsible for a critical enterprise workflow deserves a different analysis.

The architecture should know which dependencies are convenient.

And which have become structural.

Cloud computing allowed many business leaders to treat physical infrastructure as abstract.

AI is making the physical layer visible again.

Machine intelligence ultimately depends on:

• accelerators
• memory
• networks
• data centers
• electricity
• cooling
• physical capacity.

The rapid expansion of AI infrastructure has made power availability, accelerator supply and data center capacity material constraints on the growth of machine intelligence.

These constraints may appear distant from an individual enterprise consuming model APIs.

They are not.

They influence:

• pricing
• capacity availability
• regional expansion
• latency
• provider strategy
• contract structures
• and resilience.

Machine intelligence is software experienced through physical infrastructure.

The economics of the operating model eventually reach the power grid.

The International Energy Agency has documented the rapid increase in electricity demand associated with data centers and AI workloads, with data center electricity consumption projected to rise substantially through the second half of the decade.

Major cloud and technology providers are simultaneously committing unprecedented capital to AI infrastructure, including accelerators, networking, data centers and energy supply.

These investments demonstrate that AI capacity is not infinitely elastic.

The enterprise consuming intelligence through an API may not own this infrastructure.

But it still consumes the productive capacity the infrastructure creates.

Traditional infrastructure capacity planning asks how much technical demand the system will generate.

AI Native capacity planning must also ask how much productive machine capacity the enterprise intends to create.

This connects infrastructure planning to workforce and operating planning.

If a business unit intends to deploy agents across a high volume workflow, the enterprise should understand the resulting inference demand before deployment.

If a new operating model moves substantial work from human execution into machine execution, the financial model should capture the infrastructure consequence.

If an agent population can expand dynamically, capacity controls must prevent unbounded consumption.

Machine workforce planning and infrastructure capacity planning become connected disciplines.

The enterprise can begin with outcomes.

• How much work is expected?
• How much will remain human?
• How much will become machine executed?
• What models will the execution require?
• How many reasoning cycles?
• How much context?
• How many tools?
• How much evaluation?
• How much redundancy?

The result is an estimate of machine capacity demand.

That demand can then be translated into infrastructure requirements and economic budgets.

This connects the business forecast to the machine infrastructure forecast.

Compute stops being an opaque technology expense.

It becomes part of operating capacity planning.

Cloud FinOps emerged because elastic infrastructure created a management problem.

Organizations needed visibility, accountability and optimization.

AI creates the same problem with additional complexity.

• Consumption can occur inside model reasoning.
• Costs can cross providers.
• One agent can invoke another.
• Different models have different economics.
• Context size changes cost.
• Retries change cost.
• Evaluation changes cost.
• The same workflow can consume different amounts on different executions.

AI FinOps therefore cannot be only a monthly report showing model spend.

It must connect consumption to execution.

The enterprise needs to know:

• who consumed machine capacity
• which workflow consumed it
• which agent consumed it
• which model was used
• why that model was selected
• what the execution cost
• what outcome was produced
• whether a cheaper architecture could produce the same result.

This information allows optimization.

Not indiscriminate cost reduction.

Optimization.

The distinction matters.

Reducing machine expenditure while reducing enterprise value is not efficiency.

It is degradation.

The final step matters.

FinOps should not exist only to reduce expenditure.

It should help the enterprise move machine resources toward the places where they produce greater economic value.

The economic promise of machine execution is not that compute is cheap.

It is that machine capacity can produce useful work at economics that differ fundamentally from human labor.

A workflow that previously required one thousand hours of human effort may require far less human effort when machine execution performs large portions of the work.

That can create operating leverage.

But only if the infrastructure cost required to produce the outcome remains below the value created.

This relationship can change.

A poorly designed agent system can consume substantial compute while producing little value.

A well designed workflow can use inexpensive models to remove large amounts of coordination or execution effort.

Infrastructure does not create leverage by itself.

Architecture converts infrastructure into leverage.

The enterprise now has several forms of productive capacity.

The operating model must allocate work across them.

This creates a capacity portfolio.

The AI Native enterprise does not optimize one resource.

It optimizes the complete execution portfolio.

The economics of compute ultimately return the publication to its starting point.

The objective is the strongest execution system for the outcome.

Compute is another productive resource.

An extraordinary one.

But it remains a resource.

This is why the AI Native enterprise must connect infrastructure all the way back to value.

The complete relationship can now be stated.

The enterprise measures the relationship.

Then it reallocates capacity.

This is the economic operating loop of machine execution.

The architecture creates the bill.

The outcome determines whether the bill was worth paying.

The publication has now established the execution system.

The enterprise can redesign workflows.

But none of those capabilities establishes that transformation has created economic value.

The enterprise must now answer the question that determines whether AI Native transformation deserves to scale.

What economic value did the operating model create?

That is the next layer of the AI Native Operating Model.

11 · From Productivity to Economic Value