Skip to main content

SaaS Isn't Dead, but Per-Seat Pricing Might Be

SaaS Isn't Dead, but Per-Seat Pricing Might Be

I've sat in enough boardrooms this year to notice a pattern: every CIO has an opinion on whether SaaS is dying, and none of them agree on where the line is. The loudest voices on social media have already written the obituary. I think they're half right, and the half they're wrong about is the half that matters for what you do next quarter.

The Pundits Have the Diagnosis Right, the Prognosis Wrong

The claim isn't crazy. Gartner projects that 40% of enterprise applications will carry task-specific AI agents by the end of 2026, up from under 5% a year earlier. That is a real, fast shift, and it is already showing up in how vendors price and package their products. But "pressure" and "death" are different diagnoses, and the pundits keep reaching for the second one because it's the more shareable headline.

IDC put it more carefully: SaaS isn't dying, it's metamorphosing into outcome-based and usage-based economics. That's the distinction Wall Street is starting to figure out too — it's still unclear where the edges are, and how far pricing gets driven down to accommodate an AI agent doing work a human used to do. Per-seat pricing, the model that funded two decades of SaaS growth, is the part that's genuinely under threat. The category itself is not.

Where SaaS Still Earns Its Keep

Here's the test I'd apply, and it's the same one I use when a client asks whether to build or buy: how many datasets, and how many rows, does this process actually touch?

A small, single-purpose app — one workflow, one dataset, a UI wrapped around a handful of API calls — is exactly what an AI agent can now reproduce in an afternoon. That category is genuinely at risk, and it should be. But the moment you're talking about hundreds of interlocking datasets and thousands of rows with real referential integrity between them, the calculus changes. Someone has to write the logic that governs how those datasets relate, what's allowed to touch what, and what happens when they don't reconcile. App developers — including the AI vendors themselves — already wrote that logic once. Re-deriving it from scratch with a language model, every time, for every customer, is expensive in tokens and imprecise in a way that matters when the output is a financial close or a payroll run.

That's the part the SaaS-is-dead crowd keeps skipping past. The more complex and intertwined the process, the more the existing application — SaaS or on-premise — stands on its own, not because incumbents have inertia on their side, but because inefficient token use and imprecision are real costs, not hypothetical ones.

We've Run This Movie Before

I've been doing this long enough to have sat through a few "X is dead" cycles. No-code was going to kill custom development. The cloud was going to kill the data center outright, not just shrink it. Low-code platforms were going to kill the need for a real engineering team. Each time, the underlying pressure was real — pricing came down, some categories genuinely shrank, some vendors didn't survive, but the extinction-level framing was always wrong. It skipped the step where the incumbents adapt their pricing and their product to the new baseline instead of standing still and getting run over.

The cloud didn't kill the data center; it killed the case for owning one when you didn't need to, and pushed everyone who still had a real reason to run their own infrastructure into doing it more deliberately. I expect the same here. SaaS doesn't die. The SaaS vendor who assumed seat count would grow forever, with no plan for what happens when an agent does the seat's job, is the one who's in trouble — and a fair number of them will not make the transition in time.

A Concrete Example:

Take a mid-size company's month-end close. It touches the general ledger, sub-ledgers for AR and AP, a payroll system, a handful of banking feeds, and whatever spreadsheet somebody built to reconcile the gap between them. An AI agent can absolutely draft the reconciliation narrative, flag anomalies, and write the explanatory notes faster than a staff accountant. What it should not be doing is re-deriving, from scratch, the accounting logic that governs how a AP accrual rolls into the GL, or what happens when a payroll run lands on the wrong side of a period boundary. That logic already exists, encoded and tested, inside the ERP or the accounting platform. The efficient move is the agent calling into that system the way a well-trained analyst would, not the agent rebuilding the analyst's training from the model's own reasoning every single time. That's the difference between an agent that's a force multiplier and one that's an expensive, occasionally wrong, reimplementation project.

The AI agent would write the code and re-use it rather than creating it from Scratch!

The Real Fight Is Moving to the Interface Layer

If the category survives on complexity, the next fight isn't "SaaS vs. agents." It's over who controls how an agent gets at the data inside the SaaS app in the first place. This is where I'd tell a CIO to actually spend attention, because it's the part still getting built in real time.

The vendors who come out ahead here are the ones making it easy for an AI to understand what it's looking at and traverse the data with the right security boundaries intact, not exposing a raw database and hoping for the best. That's a governance problem as much as a technical one: row-level permissions, audit trails, and scoped access all have to survive being handed to an agent that might touch ten systems in one session. Protocols like MCP exist precisely because "give the model an API key and hope" doesn't hold up under a compliance review. The vendors treating this as a first-class product surface, not a bolt-on integration, are the ones who turn agentic AI from a threat into a distribution channel for their own logic.

What I'd Tell a CIO

Don't budget next year as if your SaaS stack disappears. Budget as if your per-seat line items get renegotiated hard, especially anywhere seat count was really a proxy for headcount doing repetitive work. Ask every vendor renewal two questions: what happens to my price if my human seat count drops by half because agents are doing the work, and can I let an authorized agent query this system directly, with the same permission model my humans have, without you charging me for a new "AI seat" on top of the seat I already pay for. They will most likely come at you with "indirect licensing" if you are bringing your own models.

The vendors with good answers to both questions are the ones building for where this actually lands. The ones stalling are hoping the exaggeration wins the argument long enough to protect this year's renewal.

If you're wrestling with where your own stack sits on that line? What's genuinely at risk versus what's about to get more valuable? That's a conversation worth having before the next renewal cycle, not after. Reach out if you want a second set of eyes on it.

Comments