When Software Starts Doing the Work, the Economics Change
For most of the SaaS era, the economic relationship between customer and software vendor was relatively straightforward.
The vendor provided software that helped people perform work. The customer paid for access to those capabilities and provided the people, processes and other resources required to turn them into business outcomes.
A CRM helped a salesperson manage opportunities.
Marketing automation helped a marketer execute campaigns.
Customer service software helped an agent resolve issues.
Software could automate parts of that work and make people faster or more effective, but people remained responsible for a significant portion of the work.
Agentic software is changing that relationship.
It can now research, analyze, decide, create, test, coordinate, and execute. It can assist with a task, complete the task itself, or take on increasingly complex combinations of work, within the authority and governance it is given.
That changes more than what software can do.
It changes the economics for the customer buying the software and for the vendor providing it.
This Isn’t Just a Pricing Discussion
There is already significant ongoing discussion about what AI agents mean for traditional SaaS pricing.
Software pricing has often relied on proxies for value: users, features, data volumes, transactions, or other measures of access and consumption. These models use metrics that are relatively simple to measure and often correlate reasonably well to the scale at which customers use the software, and to a degree the benefit they receive.
Agentic software can weaken those relationships.
The same number of users, customer records, or features can now support very different quantities and types of work performed by the software. And as agentic capabilities increase, the software may perform work that previously required substantially more human effort.
That makes it increasingly important to distinguish between three things:
what is easy to measure
what it costs the vendor to deliver
what creates economic value for the customer
Easy to measure ≠ Vendor cost ≠ Customer value
A token, model call, agent action, or completed task may be easy to count. It may also contribute directly to the vendor’s cost. But that doesn’t tell us how much economic value was created for the customer.
More AI consumption does not automatically mean more value. Neither does more work performed. Software could generate more content, execute more campaigns, analyze more records, or complete more tasks without producing a corresponding improvement in revenue, cost, customer experience, risk, or another meaningful business outcome.
This change has driven interest in consumption, usage, completed-work, and outcome-based pricing models. Salesforce’s Agentforce portfolio alone now includes per-user, per-conversation, per-action, and per-resolution pricing. Four pricing models from a single vendor show how unsettled the economics of this work still are.
But moving from one pricing model to another addresses only part of what is changing.
As software takes on work previously performed by people, the economics around that work begin to shift as well. The customer may reduce or redistribute the human effort and other costs required to perform the work, while potentially gaining speed, scale, quality, or other economic benefits. At the same time, the vendor increasingly incurs AI, computing, infrastructure, and other costs as its software performs that work.
The more fundamental shift is a redistribution of work, cost and value between the customer and the software vendor.
Understanding that shift requires looking at the economics from both sides.
One Piece of Work, Two Economic Perspectives
Before looking at the economics from either side, it helps to separate three questions:
Capability: Can the software perform the work?
Value creation: Does having the software perform that work create meaningful economic value for the customer?
Economics: Does that value exceed the customer’s total cost—and can the vendor deliver the work at attractive economics?
These questions are related, but they are not the same. Software can be capable of performing work that creates little incremental customer value. It can also create substantial customer value while being uneconomic for the vendor to deliver.
That is why the work needs to be considered from both sides.
Customer economics
Value Created by Agentic Work − Total Cost to Realize That Value = Customer Net Value
For the customer, the question is how much value the work creates and what it costs in total to realize that value: not only software fees, but implementation, integration, oversight, and the human effort still required.
Vendor economics
Revenue from Agentic Work − Cost to Deliver That Work = Vendor Margin
The vendor sees the same work differently. For the vendor, the question is how much revenue it can earn as its software performs more of the work, and what that work costs to deliver: AI and computing, infrastructure, support, and ongoing development.
Both equations have to work for mutual success.
Agentic capabilities can create significant customer value but be unattractive for the vendor because the commercial model realizes too little revenue from the value being created.
The reverse is also true. The total realized cost of an agentic capability (purchase and subscription fees, AI or usage charges, implementation, integration, oversight and the human effort still required) can outweigh the value for the customer.
Agentic Software Changes the Division of Work
As software takes on more work, it becomes important to understand what actually happens to the work previously performed by people and what new work becomes possible. There are four primary impacts on the work:
Elimination — Work is no longer required because changes to the process remove the need for it altogether. This might include handoffs, reconciliation, rework, or other activities that existed because of how the work was previously performed.
Shift — Work that still needs to be performed moves from people to software. Research, analysis, content creation, decision-making, coordination, or execution that was previously performed by people can be performed by software. Work can also shift elsewhere in the organization as automation in one part of a process creates new requirements in another.
Change — As software takes on more execution, people may spend less time completing individual tasks and more time establishing objectives, providing context, exercising judgment, granting authority, reviewing exceptions, and providing oversight.
Creation — Work that wasn’t economically practical before may become viable. A business might analyze more interactions, evaluate more alternatives, personalize more decisions, or act on opportunities that previously would not have justified the time and resources required.
These impacts can happen at the same time: automating a process might eliminate hours of routine execution while creating new requirements for oversight or exception handling. Software might dramatically increase the number of decisions or actions a business can execute, but also create additional work elsewhere in the process.
And replacing one type of human effort with another does not necessarily reduce cost, particularly if the remaining work requires more expensive skill sets or relies on people with limited capacity. In the latter case, the work can also become a bottleneck that limits speed, scale, and ultimately the value that can be realized.
This is why measuring how much work software performs, including how much human work it appears to replace, doesn’t provide the full economic picture.
We also need to understand how the type, quantity, location, and cost of existing work change, and the economic value of new work that becomes possible.
Agentic software therefore changes more than the division of existing work between people and software. It can also expand the work an organization can economically perform.

More Work Performed Doesn’t Necessarily Mean More Value
Changing the division of work can create incremental value for the customer in several ways:
Lower costs: reducing the time and resources required to perform existing work.
Increased capacity: enabling an organization to perform more work with the same resources.
Higher quality: making work more accurate and consistent.
New capabilities: making work feasible that wasn’t economically practical before.
But these benefits don’t grow in step with the amount of work performed. The incremental value of additional work can vary significantly. Ten additional high-quality decisions may create substantial value, while thousands of additional recommendations, messages, or actions may create relatively little.
Consider an agent optimizing email campaigns for an online retailer. It can test more audiences, content, and send times, and execute far more campaigns than the team could manually. Initially, that additional work might improve conversion without requiring more people. But at some point, more messages may add little incremental revenue while increasing unsubscribes, deliverability issues, AI consumption, and the human oversight required. If the vendor is paid per message or action, its revenue can continue growing even after the customer’s incremental value has flattened.
The software is performing more work. That isn’t the same as creating more net value.
Other costs may also increase, including implementation, integration, data, and governance. And constraints elsewhere in the process may limit how much of the potential value can actually be realized.
The same applies on the vendor side. As software performs more work, the vendor may generate more revenue by creating more value for the customer, but performing that additional work can also increase AI, computing, infrastructure, and other delivery costs. The revenue the vendor captures does not necessarily increase at the same rate as the value created for the customer, nor does the vendor’s cost to perform the work necessarily increase at the same rate as its revenue.
These relationships do not necessarily move together or linearly.

The Economics Have to Work—on Both Sides
As software performs more work, two economic questions become important:
Does the incremental value created for the customer exceed the incremental cost required to realize it?
Does the incremental revenue generated for the vendor exceed the incremental cost of delivering that additional work?
The economically attractive point isn’t where software performs the maximum amount of work. It is where the work creates meaningful net value for the customer while also supporting sustainable economics for the vendor.
That has implications for how agentic software is designed, packaged and ultimately priced. A vendor may have an economic incentive to increase AI consumption or agent activity, particularly when revenue grows with usage. But additional usage does not necessarily create corresponding value for the customer.
The longer-term opportunity is to identify where software can perform economically valuable work, and build a lasting commercial model that allows both the customer and vendor to benefit from it.
Moving from Capability to Economic Value
Agentic software creates the potential for significant economic value. But realizing that potential depends on more than whether the software is capable of performing the work.
What comes next depends on the economics of the work: the value it creates, the total cost required for the customer to realize that value, and the cost for the vendor to deliver it.
This is why the transition to agentic software cannot be understood simply as a technology shift or a move from seats to usage-based pricing. It changes the underlying economic relationship between the customer and the software vendor.
Navigating that shift means understanding where agentic capabilities create meaningful economic value, what it costs to create and realize that value, and how it is shared between customer and vendor.
And that raises another question: if software increasingly performs the work, what should the commercial model actually be based on?