Per-Seat Is Dying: How Agentic AI Rewrites SaaS, Procurement and Build-Versus-Buy

Introduction

The software industry runs on per-seat pricing. You pay for the number of people using the tool. The logic is simple: more users, more value, more revenue.

Speculation AI is quietly dismantling that logic. Per-seat pricing assumes a stable relationship between the number of people and the amount of work done. Agentic AI breaks that assumption.

When one person directing agents can do the work of five, the number of seats stops tracking value. Interpretation This is not a minor pricing adjustment. It is a structural shift that rewrites SaaS economics, procurement strategy, and the build-versus-buy decision.

Why Per-Seat Breaks

SpeculationThe logic is straightforward: a single employee equipped with agents can produce the output of five employees without agents. The buyer needs fewer seats to achieve the same result. The vendor is penalised by their own product's effectiveness.

Value has migrated from the human to the agents. But the pricing model still charges for the human.

Where per-seat survives

Speculation Per-seat pricing survives where the human genuinely is the unit of value:

• Collaboration tools where the value is in connecting people
• Identity and access management where the seat is the security boundary
• Compliance tools where the seat is the audit unit

But for productivity tools, analytics platforms, and workflow automation, per-seat pricing is under pressure.

The Pricing Model Transition

Interpretation Enterprise software pricing is moving through a spectrum of models, each with different risk profiles and value alignment.

Per seat

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

Buyer advantage: Predictable budgeting, simple access control.

Vendor advantage: Recurring revenue, expansion linked to headcount.

Breaks when: Agents perform work without proportional seat growth.

Per action

Charge for generated assets, resolutions, transactions or tool executions.

Buyer advantage: Closer to actual work performed.

Vendor advantage: Revenue scales with usage.

Risk: Can reward activity rather than success. High-volume, low-value actions may cost more than outcomes justify.

Per workflow

Charge for orchestrated processes or runs.

Buyer advantage: Matches agentic systems and multi-step processes.

Vendor advantage: Captures value of orchestration, not just individual calls.

Risk: Workflows vary dramatically in complexity and outcome. A simple workflow and a complex one may have the same price but different value.

Per capacity

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

Buyer advantage: Transparency into production cost.

Vendor advantage: Direct cost recovery.

Risk: Transfers consumption volatility to buyer. Requires buyer to manage demand and optimize usage.

Per outcome

Charge for resolved cases, recovered revenue, completed goals or measured business results.

Buyer advantage: Price aligns with value. Pay for results, not activity.

Vendor advantage: Can charge premium for proven outcomes.

Risk: Requires precise outcome definition, attribution, and measurement. Vendor absorbs delivery risk. Can be more expensive than other models when risk premium is priced in.

Hybrid

Platform fee plus usage bands, outcome bonuses, or capacity overages.

Interpretation This is the likely near-term destination for most enterprise contracts: predictable base access combined with variable intelligence consumption.

Vendor Margin and Risk Transfer

Interpretation AI features create new variable costs inside products historically sold with high software gross margins. Vendors must decide how to absorb or pass through these costs.

The vendor's dilemma

A vendor offering “unlimited AI” within a seat absorbs all consumption risk. This creates pressure to:

• Route to cheaper models
• Constrain quality or features
• Throttle usage silently
• Add fair-use limits
• Increase seat prices
• Segment features by tier

Who absorbs volatility

Vendor absorbs: Buyer gets certainty. Vendor manages usage risk through routing, throttling, or margin compression.

Buyer absorbs: Vendor gets cost recovery. Buyer manages demand, optimization, and budget volatility.

Shared risk: Committed capacity, bands, floors and ceilings distribute forecast risk between parties.

The gross margin question

Interpretation Enterprise buyers should ask not only what the feature costs today, but what happens when adoption succeeds. A vendor under margin pressure may:

• Change pricing mid-contract
• Degrade quality through model substitution
• Add usage caps retroactively
• Increase renewal prices materially

Contracts should address these scenarios explicitly.

Per-Outcome Pricing and Its Risks

Speculation The natural successor to per-seat pricing is per-outcome pricing: you pay for results, not seats. In theory, this aligns price with value. In practice, it introduces new risks for both buyer and seller.

For the seller

Per-outcome pricing transfers delivery risk from the buyer to the seller. The seller now owns the outcome, not just the tool. This requires:

• Agreeing on what counts as a successful outcome
• Building systems that can measure and prove outcomes
• Accepting revenue volatility based on customer success

For the buyer

Per-outcome pricing can be more expensive than per-seat if the vendor prices in the delivery risk. It also creates dependency: if the vendor owns the outcome, the buyer loses control over how it is achieved. And it creates gaming risk: what happens when the vendor optimises for the metric instead of the real outcome?

What Outcome-Based Procurement and SLAs Would Require

Speculation If pricing moves toward outcomes, procurement and SLAs need to evolve. Here is what outcome-based contracts would require:

1. Precise, jointly-agreed outcome definition

What counts as success? What does not? Who decides? This is harder than it sounds. “Improve customer satisfaction” is not an outcome definition. “Reduce average handle time by 15% while maintaining CSAT above 4.2” is.

2. Service levels as outcome quality, not uptime

Traditional SLAs measure uptime and latency. Outcome-based SLAs need to measure outcome quality: accuracy, completeness, timeliness, and business impact.

3. Clear liability for autonomous actions

If an agent makes a decision that causes harm, who is liable? The vendor who built the agent? The buyer who deployed it? The person who directed it? This is a legal question that most contracts do not yet address.

4. Transparency on cost

Outcome pricing can obscure unit economics. Buyers need visibility into what they are actually paying per outcome, not just the total bill.

5. Exit terms for self-hosted or on-device

Speculation As AI moves toward on-device and self-hosted deployment, buyers need clear exit terms: what happens to the data, the models, the integrations, and the outcomes when the contract ends?

6. The hardest clause: attribution

How do you prove that the outcome was caused by the vendor's tool, not by something else the buyer did? This is the attribution problem, and it is genuinely hard.

Essential Contract Clauses for AI-Intensive Software

Interpretation Traditional SaaS contracts were not designed for AI consumption economics. The following clauses should be standard in AI-intensive procurement.

1. Telemetry and usage visibility

Requirement: Buyer receives usage data by team, product, workflow, and model where technically feasible.

Why it matters: Without visibility, buyers cannot optimize, forecast, or validate bills.

Vendor resistance: Competitive intelligence, implementation complexity.

Compromise: Aggregated data with privacy controls, phased implementation.

2. Model disclosure and substitution rights

Requirement: Vendor discloses which models are used. Material model changes require notice and buyer approval or exit rights.

Why it matters: Model changes can affect quality, latency, cost, and data handling.

Vendor resistance: Operational flexibility, competitive advantage.

Compromise: Disclosure of model class (frontier, mid-tier, specialized) with performance SLAs that must be maintained.

3. Quality and performance SLAs

Requirement: Define acceptable accuracy, latency, and outcome quality. Service credits for material degradation.

Why it matters: A cheaper model route is not equivalent if quality changes.

Vendor resistance: Liability exposure, measurement complexity.

Compromise: Tiered SLAs by criticality, joint measurement methodology.

4. Caps, bands, and alerts

Requirement: Usage caps, spending bands, automatic alerts at thresholds, approval gates for overages.

Why it matters: Prevents runaway consumption and budget surprises.

Vendor resistance: Revenue limitation, implementation cost.

Compromise: Soft caps with alerts, hard caps for non-critical workloads.

5. Data and workflow portability

Requirement: Buyer can export prompts, workflows, evaluation data, and outcomes in usable formats.

Why it matters: Reduces switching cost and vendor lock-in.

Vendor resistance: Competitive moat, implementation burden.

Compromise: Standard export formats, phased implementation, reasonable fees for bulk export.

6. Price change and renegotiation rights

Requirement:Material price changes trigger renegotiation or termination rights. Define what constitutes “material”.

Why it matters:Vendor's model costs may change dramatically. Buyer needs protection.

Vendor resistance: Revenue predictability, market flexibility.

Compromise: Annual price review with caps on increases, shared savings mechanisms.

7. Agent identity and accountability

Requirement: Clarify whether agents count as users, how agent-to-agent calls are billed, and who is liable for agent actions.

Why it matters: Prevents surprise charges when one agent triggers multiple downstream agents.

Vendor resistance: Pricing model complexity, liability exposure.

Compromise: Clear definition of billable agent activity, liability framework based on autonomy level.

The Buy-Partner-Beats-Build Evidence

Evidence MIT NANDA research (2025) found that buying or partnering for AI capabilities succeeded roughly twice as often as building internally. The reading: the default should be buy-or-partner, not build.

Interpretation Building should be reserved for genuine differentiation: capabilities that are core to competitive advantage and cannot be bought. For everything else, buy or partner.

This matters because the disruption in SaaS pricing flows through specialist vendors. The organisations that default to building will miss the pricing innovation happening in the market.

The Incumbent's Dilemma

Speculation Incumbent SaaS vendors face a structural problem: their revenue is built on a per-seat model that AI is eroding. Moving to outcome pricing cannibalises their own base. And they are competing with AI-native challengers who have no legacy pricing to protect.

The three paths

1. Defend per-seat: Keep the existing model, add AI features, hope the value justifies the price. This works until a challenger offers the same outcome for fewer seats.

2. Hybrid pricing: Offer both per-seat and per-outcome tiers. This preserves the base while experimenting with new models. But it creates complexity and risks confusing buyers.

3. Full transition: Move entirely to outcome pricing. This is the boldest move, but it requires rebuilding the entire go-to-market motion and accepting near-term revenue volatility.

Speculation The pattern from previous technology waves: incumbents that try to bolt new technology onto old business models rarely transform. The winners are usually the ones willing to disrupt their own pricing.

The Argument: Disruption or Durability?

There are two competing views on what happens to incumbent SaaS vendors:

The disruption case

Per-seat pricing is doomed. AI-native firms with outcome-based pricing will move faster, price more aggressively, and win the market. Incumbents will be disrupted by challengers who have no legacy to protect.

Evidence for: Every major technology transition has created new winners. Cloud disrupted on-premise. Mobile disrupted desktop. AI will disrupt SaaS.

The durability case

Incumbents have data, distribution, and trust. They can afford to experiment with pricing. They have existing customer relationships. And they can acquire AI-native challengers before they become threats.

Evidence for: Microsoft, Salesforce, and Adobe have all successfully navigated major technology transitions. Incumbency is an advantage, not a liability.

The synthesis

Interpretation Both halves are probably true. Pricing will move toward outcomes, but slowly. Some incumbents will transition successfully. Others will be disrupted. The winners will be the ones that combine data, distribution, and trust with a willingness to disrupt their own pricing.

What This Means Now

For procurement teams, this is not a distant future problem. It is happening now. Here is what to do:

1. Stop treating seat count as a measure of value

Seat count is an input, not an outcome. Start measuring outcomes: cost per successful action, cost per business result, attribution coverage.

2. Build procurement capability to define and audit outcomes

Outcome-based contracts require new skills: defining success criteria, measuring outcomes, auditing vendor claims, and managing attribution disputes.

3. Default to buy-or-partner, reserve build for differentiation

Evidence The MIT NANDA evidence is clear: buying or partnering succeeds more often than building. Reserve internal builds for capabilities that are genuinely core to competitive advantage.

4. Negotiate outcome-based pilots now

Speculation The vendors that figure out outcome pricing first will have an advantage. Start negotiating outcome-based pilots now, even if the main contract is still per-seat. Learn what works before the market forces the transition.