Software as a service made one core promise: instead of buying and running software, you rent access to a place where your team does the work. Salesforce gives your salespeople somewhere to record deals. Your team still records them.
Agentic systems propose something different. Not a better place to do the work, but software that does a portion of it. That distinction sounds like a marketing line until you follow it through to pricing, procurement and headcount planning, at which point it stops being abstract.
Why per-seat pricing comes under pressure
The per-seat model rests on an assumption so basic it is rarely stated: value scales with the number of humans using the software. Thirty salespeople need thirty licences. The vendor's revenue grows as your team grows.
Now suppose an agentic system handles the qualification and follow-up that four of those thirty spent most of their week on. Those people move to higher-value work, or the team simply stays flat while volume grows. Either way the relationship between headcount and software value has come loose. You are not buying seats, you are buying throughput.
Vendors see this clearly, which is why pricing experiments are appearing across the category: outcome-based pricing, consumption pricing, hybrid models charging per resolved case rather than per user. None of these has settled. If you are signing multi-year agreements right now, the pricing model is worth as much negotiating attention as the functionality.
A question worth asking any vendor in a renewal conversation: if our headcount falls while our transaction volume rises, does our bill go up or down? The answer tells you whether their model has adapted to agentic reality or is still counting humans.
What actually changes in the software itself
Traditional business software is fundamentally a structured interface onto a database. Forms constrain what you can enter, workflows move records between states, reports aggregate what is stored. The intelligence lives in the people operating it.
An autonomous system inverts that. The interface matters less because fewer humans touch it directly. What matters is whether the system can retrieve the right context, reason about it, take action in other systems, and know when to stop and ask a person.
The practical consequence is that integration depth becomes the primary differentiator rather than user experience. A beautifully designed tool that cannot reach your other systems is less valuable than an ugly one that can. This is close to a reversal of the last decade of SaaS competitive logic, where UX polish was frequently the deciding factor in procurement.
Three things that are genuinely being replaced
Coordination software
A significant share of business software exists to move information between people: routing, assignment, notification, status tracking, chasing. This category is directly exposed, because coordination is exactly what agents do without complaint. Tools whose primary function is telling humans what to do next have the weakest position.
Data entry interfaces
Anywhere a person reads from one system and types into another, that gap is an obvious target. It is usually the first thing automated, it is unglamorous, and the savings are real and immediate.
Simple decision workflows
Approval chains where the decision follows articulable rules, and the human step exists mainly for accountability rather than judgement. These do not disappear, but they invert: the system decides and the human reviews exceptions, rather than the human deciding on every instance.
Three things that are not going anywhere
Systems of record
Something still has to hold the authoritative version of your customers, transactions and history, with proper access control, backup and audit. Agents read from and write to systems of record; they do not replace them. If anything, data quality in the system of record becomes more critical, because an agent acting on bad data acts faster and at greater scale than a human would.
Specialised domain software
Tools encoding deep regulatory or engineering knowledge, actuarial platforms, clinical systems, CAD, are not threatened by generalist agents. The domain logic took decades to accumulate and is not sitting in a language model's weights.
Anything where the interface is the product
Creative tools, analytical environments, anything where a skilled human is directly manipulating something. Agents assist here; they do not substitute.
The honest state of play
It would be dishonest to present this transition as further along than it is. Most businesses running agentic systems today are running them in narrow, well-bounded domains: one process, one department, clear guardrails. The autonomous enterprise is a direction of travel, not a current condition.
What has genuinely changed is the direction. Five years ago, software that could take multi-step action on your behalf was research. Now it is a procurement decision with real vendors and real reference customers. The question has moved from whether this works to where it should be applied first.
What this means for how you buy software
Three practical shifts worth making now, regardless of how quickly you intend to adopt agents.
Weight API access heavily. A tool that cannot be reached programmatically is a tool that cannot participate in an automated process. Check not just whether an API exists, but whether your licence tier includes it and whether it covers write operations rather than read-only.
Shorten commitment horizons where you can. The pricing models in this category are unsettled. Five-year agreements signed on today's assumptions may look poor in eighteen months.
Ask where the data lives and whether you can get it out. The value of your operational history rises as systems become able to reason over it. A vendor holding it in a form you cannot extract holds more leverage over you than they did when it was just records.
The uncomfortable part
The disruption narrative is usually told as vendors being displaced, which is comfortable for buyers. The less comfortable version is that if agents can do a meaningful portion of what your software was helping your team do, that has implications for your team, not only for your suppliers.
Most organisations handling this well are treating capacity gains as capacity rather than as headcount reduction, growing volume without growing cost. That is a genuine strategic choice rather than an inevitability, and it is worth making deliberately rather than by default.