AI Is Turning Software Into a Variable Cost of Execution

For most of software's history, the work was still human. Software sat between a person and a task — faster than paper, more scalable than manual process, but still something humans had to pick up and operate.

AI introduces something economically different.

A model can investigate a claim, review a contract, write code, resolve a support ticket, draft a clinical note, or make a risk recommendation — without a person executing each discrete step. The software is no longer merely providing the tools to do the work. It is increasingly executing the work.

This does not mean the human disappears. It means the human moves upstream — from executing the work to directing, constraining, and supervising it. A supervisor overseeing fifty autonomous agent workflows is still a human making consequential decisions. But their judgment was expressed at policy-setting time, not task-execution time. The ratio of human work per unit of output is shrinking. And the connection between the human's decision and the action the system takes is becoming more indirect, more distant, and harder to trace after the fact.

AI is not labor in the legal or human sense. But it is becoming a variable production input that performs portions of knowledge work once performed only by labor.

When the economic unit shifts from access to work performed, pricing has to respond too. Seat pricing rested on a foundational assumption: that the human was the proximate creator of value. When an agent executes the workflow under upstream human direction, the seat no longer measures where value is created.

AI isn't eliminating software pricing. It is changing what software is being sold for.

Separating Cost, Pricing Metric, and Value

Much of the confusion in AI monetization comes from collapsing three distinct concepts:

• Cost: What it costs the vendor to deliver the service — tokens, inference compute, tool integrations, human review, infrastructure, and compliance.
• Pricing Metric: The billable unit on the invoice — seat, token, transaction, workflow, or assured outcome.
• Value: The economic benefit the customer captures — cost avoidance, capacity expansion, risk reduction, or error mitigation.

graph LR
    A[Vendor Cost-to-Serve\nTokens, Inference, Compute] -.->|Decouple| B[Billable Pricing Metric\nSeats, Workflows, Assured Units]
    B -->|Aligns With| C[Customer Realized Value\nThroughput, Risk Reduction, Savings]

Infrastructure providers (OpenAI, Anthropic, AWS) legitimately sell compute via token meters because compute is their product.

When application software vendors inherit token meters, they confuse vendor cost with customer value. Token consumption measures how much compute a prompt consumed, not whether the output solved a business problem. A 500-token output that resolves a critical compliance breach is immensely valuable; a 5,000-token verbose summary of a routine email is near-worthless.

Tokens are a cost driver. They are not automatically a customer-value metric. Good AI pricing separates the vendor’s cost-to-serve from the customer’s reason to pay.

How the Economic Unit of Software Has Evolved

The appropriate way to price software follows what the customer is purchasing and how risk is allocated:

graph TD
    A[SEAT: Human does the work, Software provides access\n$/user/month] --> B[USAGE: AI assists the human, Software consumes compute\n$/token or $/unit of inference]
    B --> C[WORK: AI performs tasks, Software delivers output\n$/transaction or $/workflow]
    C --> D[ASSURED WORK: AI performs consequential work\nwithin defined bounds with evidence\n$/completed work + assurance]

• Seat (Access): The customer buys the right to access software. All execution risk and labor costs remain with the customer. Seat pricing remains effective when humans perform the substantive task.
• Usage (Compute): The customer pays for raw compute consumption. Appropriate for infrastructure layers; mismatched for business applications.
• Work (Output): The customer pays for a completed workflow — an invoice processed, a ticket resolved, a contract structured. The vendor participates economically in execution delivery.
• Assured Work: For consequential workflows, the customer pays for completed execution within defined authority, policy, quality, and evidence boundaries.

For consequential enterprise workflows, the credible progression is not from seats directly to ultimate outcome pricing. It is from access, to observable work, to assured work: execution that is completed within agreed policy, quality, authority, and evidence boundaries.

Three Ways AI Interacts With Labor

The appropriate commercial model depends strictly on how the product interacts with human workflow execution:

graph LR
    A[AI Interaction Mode] --> B[Augmentation]
    A --> C[Workflow Substitution]
    A --> D[Execution]
    B -->|Users more productive, headcount stable| E[Seat Pricing Holds]
    C -->|Agents execute multi-step workflows| F[Seat Pricing Breaks]
    D -->|Software performs end-to-end tasks| G[Work-Unit Pricing Emerges]

AI Augmentation: Ten employees use AI to produce 50% more output. Seat pricing holds because headcount is stable and value per seat increases. Much of enterprise AI today remains here. For product leaders building copilot and productivity tools, seat pricing remains appropriate for now—the leading indicator of change is when enterprise buyers begin asking for autonomous background execution or when seat counts start consolidating.

Workflow Substitution: Ten analysts become two supervisors managing autonomous workflows. Seat pricing becomes self-defeating: the more effective the software, the fewer seats the customer buys. The product delivers higher value, yet legacy pricing punishes vendor revenue.

AI Execution: The system functions as an automated workforce completing end-to-end transactions under human policy oversight. Pricing naturally migrates toward the unit of work performed.

These interaction modes map directly to accountability: Augmentation operates as an Assist tool under human judgment; Workflow Substitution and Execution operate as Execute systems within policy gates. And when execution carries consequential business risk, the system must cross into Commit—where accountability requires proof.

The Value Story Was Always There. The Billing Mechanism Wasn't.

This isn't a new problem. It is why business value consulting exists.

Teams at Oracle, Salesforce, SAP, and Google have dedicated functions whose job is to quantify ROI: "This implementation will improve claims velocity by 30%, generating \$4M in annual savings."

That number helps justify a \$500K enterprise license. But the billing mechanism is still a seat count, consumption commitment, or enterprise license fee — not the \$4M of value supposedly created. If the value doesn't materialize, the customer generally doesn't get a refund.

Value realized is the story enterprise software has always sold. Seats and licenses are the mechanism it has historically charged through. Business value consulting exists, in part, to bridge the gap between the two.

That gap persisted because value was genuinely difficult to measure in real time. "Did your CRM increase rep productivity by 25%?" Answering that requires months of data, contested attribution, baseline comparisons, and controlled experiments. Was productivity caused by the software, new sales processes, better training, or a favorable market?

For most enterprise software, it was cheaper for both sides to agree on a seat count.

AI can change that equation — not because attribution disappears, but because the work itself is becoming increasingly observable.

Consider an illustrative claims automation deployment: an agent processes 47,000 claims in a quarter. The economic conversation can move from:

"We estimate this system will generate \$4M in annual value."

Toward:

"The system processed 47,000 claims, resolved 41,000 without escalation, achieved a 99.2% accuracy rate, and reduced average processing time by 37%."

Those metrics become billable facts when the parties agree in advance on the workflow boundary, quality methodology, exception definitions, evidence retained, and treatment of later reversals.

Crucially, observability cannot remain a vendor-side black box. If only the software provider can see the execution telemetry, a bill for 47,000 processed claims is merely an unverified assertion. For legal, regulatory, and compliance reasons, enterprise buyers require direct access to the logs. Risk and audit teams must be able to verify that policy bounds were respected, confirm when human escalations occurred, and produce an independent audit trail for regulators, counterparties, or insurers.

The value isn't merely being promised; the work is being measured and verified. And once the work becomes independently auditable, the pricing mechanism can follow the work.

The important shift isn't from subscription pricing to outcome pricing. It is from pricing access to pricing observable work — and, eventually, pricing the assurance around that work.

Assured work is attributable without requiring proof of full downstream causation. Was the claim reviewed within defined parameters? Was the contract processed correctly? Was the decision made within an authorized policy boundary? Those questions are answerable. "Did the AI cause the sale?" often is not.

The Forcing Mechanism: Why Proof Becomes Economically Necessary

More automation does not automatically create demand for proof. Organizations left to their own devices tend to avoid accountability rather than pursue it.

What creates economic pressure toward proof is external forcing:

graph TD
    A[AI Performs Consequential Work] --> B[Exposure Grows]
    B --> C[External Pressure Accumulates]
    C --> D1[Regulation: Adverse action explanations, audit requirements]
    C --> D2[Litigation: Discovery of AI governance records]
    C --> D3[Insurance: Underwriters require evidence of controls]
    C --> D4[Procurement: Enterprise buyers impose SLA and audit terms]
    C --> D5[Financial Materiality: Boards and auditors ask governance questions]
    D1 & D2 & D3 & D4 & D5 --> E[Assured Work Becomes Economically Required]
    E --> F[Vendors Who Provide It Differentiate on Price]

For low-consequence AI — a draft generator, a search assistant, a recommendation engine — proof remains mostly an internal engineering concern. The market does not yet demand it, and assured-work pricing is premature.

For high-consequence AI — clinical documentation, underwriting decisions, fraud determinations, financial advice — proof is becoming an economic requirement imposed from outside. Vendors who provide it differentiate. Vendors who don't face procurement friction, regulatory exposure, and uninsurable risk.

Defining "Assured Work" in Practice

"Assured Work" is not merely a higher pricing tier. It is a distinct product category:

• Work answers: "Did the system complete the assigned workflow?"
• Assured Work answers: "Did it complete the workflow within agreed authority, policy, quality, evidence, and remediation boundaries?"

Consider how this distinction applies to an insurance claims workflow:

The value of assurance is not that it guarantees every decision is perfectly right. No serious enterprise buyer will believe that. The value is that the system has bounded authority, defined controls, observable evidence, and a known response when it is uncertain or wrong.

In high-consequence domains — clinical documentation, credit underwriting, fraud determinations, financial decisioning — customers are not buying raw probabilistic generation. They are buying a system they can place into production without accepting unobservable, unmitigated operational exposure.

Assist, Execute, Commit: Three Tiers of AI Accountability

As AI transitions from generating text to executing business logic, product value resolves into three tiers defined by responsibility, enforcement, and evidence:

Most enterprise AI today operates between Assist and Execute. Commit is not where the market currently is across the board; it is where the economics become fundamentally different when software performs truly consequential, autonomous work.

The critical threshold is the Assist → Execute → Commit boundary:

• Assist: Software produces a candidate recommendation or draft. A human decides. All accountability remains with the human.
• Execute: Software performs a bounded multi-step workflow. Policy gates verify pre- and post-conditions. Risk begins to be shared.
• Commit: Software produces a consequential business state change within an auditable evidence trail. Risk must be allocated, not merely absorbed.

AI assists under human judgment. It executes within enforced boundaries. It commits only where evidence makes accountability allocable.

The Precedent: The Collapse of the SaaS vs. BPO Boundary

This commercial shift is not an untested theory. It is the exact economic framework that high-consequence business process outsourcing (BPO) and audit industries—such as healthcare payment integrity, revenue cycle management, and tax auditing—have used for decades.

In medical payment integrity, vendors don't sell seat licenses to human auditors. They charge through a combination of:

1. A Base Screening Fee: A fixed fee per claim ingested and evaluated (\$1.50–\$5.00 per transaction).
2. A Contingency / Gain-Share Rate: A percentage of verified overcharges or improper billings successfully corrected.
3. Reversal & Audit Reconciliation Terms: Explicit dispute windows where the client can inspect the audit log and claw back fees if an appeal later overturns the decision.

What autonomous AI is doing is collapsing the boundary between software and outsourced professional services.

When an agent executes the workflow directly, the AI company is no longer selling a SaaS application; it is operating an autonomous service layer. And its commercial contract must naturally adopt the playbook of audit and payment integrity firms: structured work units, dispute reconciliation windows, and mandatory log access.

The Commercial Reality: Hybrid Pricing Architectures

In practice, assured-work pricing in enterprise contracts will rarely be 100% variable on day one. Pure per-work or per-outcome models place too much implementation cost, exception volatility, and operational risk on the vendor before reliability baselines are established.

A mature assured-work commercial architecture is almost always hybrid:

1. A Platform Commitment: An annual base fee that funds integration, governance infrastructure, policy configuration, and reserved capacity.
2. A Variable Unit Fee: A tiered rate for completed, eligible workflows that meet defined quality and policy thresholds.
3. Complexity & Risk Adjustments: Differentiated unit rates based on transaction complexity or required human escalation depth.
4. Remediation & SLA Terms: Pre-negotiated service credits or adjustments for quality failures, with clear rules for human overrides and edge-case exceptions.

The point of assured-work pricing is not to make every dollar variable. It is to ensure that the variable component corresponds to observable work delivered rather than invisible compute consumed.

Where Pricing, Accountability, and Proof Converge

When software performs work, the customer stops needing primarily to know they have access to the software. They need to know the work was done correctly.

graph TD
    A[Compute: Foundation model providers monetize inference] --> B[Work: Application vendors monetize output]
    B --> C[Assured Work: High-consequence vendors monetize correctness]
    C --> D[Risk Transfer: Proof enables insurance and liability allocation]

This reveals the economic mechanism connecting the AI product stack:

Foundation model companies monetize compute. The token is their unit.

Application companies monetize work. The completed workflow is their unit.

High-consequence application companies monetize assurance around that work. The verified, policy-bounded, auditable output is their unit.

The moment software becomes responsible for performing the work, the customer needs more than the output. They need evidence that it was performed correctly — within authorized boundaries, within defined parameters, by a system that can be held accountable for what it did.

Without that evidence, the vendor is left pricing the machinery. With it, the vendor can price the work.

The New Unit of Software

For decades, the basic economic unit of software was access. A seat. A license. A transaction. A gigabyte.

AI introduces another unit: a piece of work.

That doesn't mean every AI product will migrate to work or outcome pricing. Many won't — because their consequence is too low, their attribution too contested, or their market not yet demanding it.

Enterprises care deeply about cost — which is precisely why raw token pricing creates procurement friction. A CFO does not want an unpredictable utility bill that fluctuates based on how many tokens or reasoning loops an agent burned to evaluate a file. They want cost predictability per unit of work: What does it cost to resolve a claim correctly within defined parameters?

They don't want to absorb the financial volatility of a vendor's compute inefficiencies or model verbosity. They want a predictable unit cost for completed, verified execution.

The closer software gets to doing the work, the more its pricing has to account for the work delivered rather than the compute burned.

If you are going to charge for work performed by software, you need to be able to prove what work it performed — and that it was performed correctly.

That is where the economics of AI and the architecture of proof meet.

Primary Sources & References

• Bain & Company: "AI Pricing: A Reality Check on Effort, Usage, and Outcomes" — Analysis of effort/usage vs. output vs. outcome monetization models in enterprise AI.
• Architecture of Proof: "The Multi-Agent Liability Trap" — August 2026. (architectureofproof.com/multi-agent-liability-trap)
• Architecture of Proof: "The EHR Integration Trap: Browser Agents as an Unmanaged Integration Layer" — August 2026. (architectureofproof.com/ehr-agent-integration-cfaa)
• Architecture of Proof: "Before AI Can Be Insured, It Must Be Provable" — August 2026. (architectureofproof.com/ai-insurability-requires-proof)

One-Line Synthesis

As software moves from providing access to performing work, the economic unit shifts from seats and compute toward completed execution. When that execution is consequential, the customer is not buying output alone; they are buying bounded, verifiable work. Assured work is the commercial model, and proof is the infrastructure that makes it credible.

Governance is not merely compliance overhead added after AI creates value. For consequential autonomous systems, governance is part of the product, part of the billable unit, and eventually part of the vendor’s ability to capture value at all.

Disclaimer: This analysis represents strategic product management and business model frameworks. It does not constitute financial, legal, or pricing advice.