The End of the Software Seat

Per-seat pricing made sense when software value and cost scaled broadly with human users. Agents weaken both assumptions.

Why the seat worked

The software seat was convenient.

It gave vendors:

• predictable recurring revenue
• simple packaging
• expansion linked to headcount
• manageable metering

It gave buyers:

• easy budgeting
• familiar procurement
• limited exposure to workload volatility
• simple access control

The seat was never a perfect measure of value. It was a practical proxy for access.

Agents break the denominator

An agent can:

• perform work for many employees
• operate without a named human session
• create machine-to-machine activity
• run continuously
• make variable numbers of calls
• replace or combine several application workflows

Headcount can fall while usage rises.

One employee can supervise many agents. One agent can serve many employees. A workflow can consume substantial AI capacity without any new seat.

The pricing units competing to replace it

Per seat

Still useful when AI remains an assistive feature tied closely to a person.

Per action

Charge for a generated asset, resolution, transaction or tool execution.

Strength: Closer to work.

Weakness: Can reward activity rather than success.

Per workflow

Charge for an orchestrated process or run.

Strength: Matches agentic systems.

Weakness: Workflows vary in complexity and outcome.

Per successful outcome

Charge for resolved cases, recovered revenue or completed goals.

Strength: Aligns price with buyer value.

Weakness: Requires definition, attribution and protection against selection effects.

Per capacity

Charge for tokens, throughput, reserved compute or agent runtime.

Strength: Reflects production cost.

Weakness: Transfers consumption risk to the buyer.

Hybrid

Platform fee plus usage bands, outcomes or overages.

Likely direction: Most enterprise contracts will combine predictable access with variable intelligence consumption.

Who absorbs volatility

Vendor absorbs it

An "unlimited AI" seat gives the buyer certainty and the vendor usage risk.

Consequences:

• fair-use limits
• hidden throttling
• quality routing
• price increases
• feature segmentation
• margin pressure

Buyer absorbs it

Metered pricing exposes consumption.

Consequences:

• better visibility
• harder forecasting
• incentive to optimise
• budget volatility

Shared risk

Committed capacity, bands, floors and ceilings share forecast risk.

This is likely to become the dominant enterprise model.

The gross-margin question

AI features create a new variable cost inside products historically sold with high software gross margins.

A vendor must decide:

• absorb token and infrastructure cost
• route to cheaper models
• constrain quality
• limit usage
• charge separately
• change packaging
• pass cost to customers
• own infrastructure
• subsidise adoption temporarily

Procurement questions

• What is the billable unit?
• What is included and excluded?
• Is underlying consumption visible?
• Are model changes disclosed?
• Are quality and latency contractual?
• What happens when usage exceeds assumptions?
• Can the vendor throttle or route silently?
• Are agents counted as users?
• Can one agent trigger charges across multiple products?
• Is data used to train models?
• What export and exit rights exist?
• Can pricing change when the provider's model cost changes?
• What outcome is the contract supposed to improve?

Contract design principles

Separate access from consumption

Know which part pays for platform access and which part pays for intelligence.

Define the work unit

Avoid vague "AI credits". Define tokens, actions, workflows or outcomes.

Require telemetry

Usage by team, product, workflow and model where technically possible.

Cap downside

Use bands, alerts, ceilings and approval thresholds.

Preserve optionality

Data portability, prompt and workflow export, model substitution and termination.

Connect price to quality

A cheaper route is not equivalent if output quality or latency changes.

Include success reviews

Revisit pricing after adoption data exists.

Relationship to value

Outcome pricing sounds ideal but is not always.

A vendor should not be paid for revenue it did not cause. A customer should not shift all business execution risk to the vendor.

Use outcome pricing where:

• outcome is observable
• attribution is reasonable
• baseline is stable
• parties control relevant variables
• quality and risk are defined

Use capacity or workflow pricing where outcomes are too indirect.

Where the seat survives

Seats will remain where:

• the product is primarily a human workspace
• AI usage is low or predictable
• marginal cost is small
• simple procurement matters more than precision
• access and governance are the core value
• the vendor can aggregate usage effectively

The claim is not that seats disappear. It is that they stop being the default denominator for AI-intensive software.

Conclusion

Agentic AI does not merely add a feature to SaaS. It changes what is being sold.

The enterprise is buying a mixture of access, intelligence capacity, automated work and risk transfer.

Pricing will have to reveal which one.

Sources

• Deloitte, The pivot to tokenomics: Navigating AI's new spend dynamics, pp. 6-7
• AI Economics Hub, "Embedded AI, Hidden Tokens"
• AI Economics Hub, "Operating Model: Procurement"