What agentic AI changes about SaaS pricing

Seat-based pricing worked because seats were a decent proxy for value. More people using the tool meant more work getting done, and the cost of serving them was close to zero, so the model was simple on both sides.

Agents break both halves at once. Value stops tracking headcount, and cost stops being fixed.

The value side

If a support agent resolves tickets without a person opening them, the customer's ideal outcome is fewer seats. You have built something whose success reduces what you charge for. That is not a pricing tweak, it is an inverted incentive.

Worse, the customers getting the most value look like your smallest accounts. A ten-person team automating the work of thirty is enormously better off and pays for ten.

The cost side

Traditional SaaS gross margins sit high because marginal cost per user is small. An agent changes that: every run costs model tokens, and heavy users cost meaningfully more than light ones.

Some illustrative arithmetic — substitute your own numbers. A run costing 30p, a customer doing 20,000 runs a month, is £6,000 of variable cost. On a £2,000 seat contract that account is deeply unprofitable, and nothing in a seat-based model surfaces it until someone reconciles the provider bill against revenue.

The failure mode is specific and common: the pricing page was written when the feature was a pilot with fifty runs a day.

Four models, and what each actually costs you

Per seat, unchanged. Simple, familiar, and now carrying uncapped variable cost. Survivable if you cap usage somewhere in the terms — which most teams do eventually, usually after a surprise.

Per run or per action. Aligns revenue with cost cleanly. It also makes customers ration usage, which suppresses exactly the adoption you want early, and it makes their spend unpredictable — which procurement hates more than it hates a high number.

Per outcome. Per resolved ticket, per processed invoice. The most honest alignment and the hardest to operate: you now need an agreed definition of "resolved" that survives a dispute, and instrumentation both sides trust. Worth it when the outcome is genuinely countable, painful when it needs judgement.

Platform fee plus metered usage. A floor that covers fixed cost, plus consumption above an included allowance. Less elegant than the others and the one most teams converge on, because it makes the base predictable for the buyer and the tail affordable for you.

What to build before you decide

You cannot choose a model without cost visibility per customer. That means, at minimum:

• Every model call tagged with the account it served
• Cost per run, aggregated per account, visible without a spreadsheet
• An alert when an account's variable cost crosses a share of its contract value
• A hard ceiling per account, enforced in code rather than in the terms

That last one is not a commercial nicety. An agent with a loop and no cap is an unbounded liability, and the discovery mechanism is the invoice.

The awkward strategic question

If the agent genuinely does the work, the thing being sold is closer to outsourced labour than to software — and labour is priced against the cost of the person it replaces, not against the cost of a licence.

That is a much larger number and a much harder sale, because the buyer is comparing against a salary and will want the assurances that come with one: accuracy commitments, audit trails, someone accountable when it is wrong.

Which is the real point. The pricing conversation and the production-readiness conversation are the same conversation. You cannot charge for outcomes you cannot evidence.