When AI makes software cheaper to build and business processes easier to automate, who gets to keep the profits?
For most of the last thirty years, software has been an extraordinary business.
Build a product once, Sell it to thousands of customers, Charge recurring fees, Keep the incremental cost of serving another customer relatively low. That’s pretty much the recipe! SaaS of course made this model even more attractive.
AI is challenging the economics behind this model in three ways.
1. It is making software cheaper to produce.
2. It is allowing customers to use applications without interacting with their interfaces.
3. It is allowing software to perform work rather than merely help people perform it.
While I do expect the total software market to grow significantly, I don’t expect the existing software companies to capture that growth in proportion to their current market positions.
My bet is that the greatest opportunity for profit will shift from selling software to taking responsibility for getting work done.
Software is becoming cheaper to reproduce
AI doesn’t make enterprise software free. Security, reliability, scalability and maintenance remain difficult. But functionality that once required a large engineering organization can increasingly be developed by much smaller teams.
A software feature is valuable partly because of what it does and partly because of how difficult it is for someone else to reproduce. When reproduction becomes cheaper, the second source of value weakens.
What happens when customers stop using the application?
Suppose I want to approve an employee’s promotion. Today I might log into an HR application, navigate through several screens, review compensation data and submit an approval. Tomorrow I might ask an enterprise agent to review the case, compare compensation, verify the budget and prepare a recommendation. Once I approve it, the agent completes the transaction.
The HR application remains important. It holds employee records, organizational structures and compensation history. But I may never open it.
This is the logic behind the argument that SaaS companies should expose their functionality through standards such as MCP and allow ChatGPT, Claude or Copilot to handle the interaction. I agree with the architectural direction – but I am not convinced by the economics.
Say a vendor earns $100 per employee per month. If customers increasingly consume those capabilities through external agents, why should the vendor automatically retain the same price? Gross margins could improve. But higher gross margins on substantially lower revenue aren’t necessarily a better business.
Of course, established vendors won’t just passively surrender all of that revenue. They can charge for API calls, introduce agent licenses, bundle their own agents with the application or restrict access to certain capabilities. Those are credible defenses, especially when switching costs are high.
A standard like MCP isn’t a real business moat, and neither is owning the agent that calls it.
Why I wouldn’t bet on orchestration alone
A common prediction is that value moves from individual applications to platforms that coordinate them. There is some truth to this. But why should the agent platform retain attractive margins?
Model providers are building agents. Hyperscalers have infrastructure, distribution and enterprise relationships. If multiple platforms can call the same tools and execute the same workflows, the orchestrator can become interchangeable too.
The difficult part is not invoking an application. It is knowing what should happen, under which circumstances, with whose permission, and what to do when something goes wrong.
The system of record is not the system of authority
Picture a bank investigating a suspicious transaction. The core banking application records it. A financial crime system identifies unusual activity. An agent gathers evidence and recommends whether to block it.
Who makes the decision?
Today, the bank’s policies establish the criteria, authorized employees or systems exercise the decision rights, and the bank remains accountable to its regulators.
AI doesn’t eliminate that structure. But it changes how much of the work can be delegated. The bank could authorize an external platform to execute predefined actions within approved policies and escalate decisions requiring human authorization. That platform would hold delegated decision rights, but not unrestricted authority.
The bank would retain ultimate regulatory accountability. The vendor could accept contractual liability for failures within its agreed responsibilities.
Decision rights can be delegated. Accountability cannot always be transferred.
In Migrating Scarcity, I argued that when intelligence becomes abundant, scarcity shifts toward the ability of institutions to absorb and authorize it. That becomes a central economic question for enterprise software.
When software does the work, pricing has to change
Take a company with 1,000 people processing invoices. Its software costs $100 per employee per month, so the vendor earns $1.2 million annually. Now assume automation allows 200 people to handle the original workload. Under unchanged seat-based pricing, the vendor’s revenue falls to $240,000.
The customer is substantially more productive. Yet the vendor has lost 80% of its revenue.
But the vendor doesn’t inevitably lose 80%. It could charge per invoice. And lower processing costs could create demand for more automation. Human users could decline while total software consumption increases.
Still, changing the pricing metric isn’t the same as changing what the company sells. Charging per invoice is still selling software if the customer remains responsible for the operation. Taking responsibility for processing those invoices correctly is a different business.
Isn’t that just outsourcing?
Taking responsibility for outcomes sounds like business process outsourcing, and there is considerable overlap.
The difference lies in how the operating capability scales. Traditional outsourcing often required additional people as transaction volumes increased. An AI-native operations provider has the opportunity to separate transaction growth from headcount growth.
But that opportunity depends on something very specific. How much work can the system complete without human intervention, and how expensive is the work it cannot?
The economics of exceptions
Imagine an illustrative AI-native operation charging $2 per transaction. A routine transaction costs $0.20 to execute. One requiring human investigation costs $12. Other operating costs add $0.40.
At 95% straight-through processing, average cost is about $1.19, a contribution margin of 40.5%. At 90%, cost rises to $1.78 and contribution margin falls to 11%.
Nothing changed about the selling price or the AI model. Only the exception rate changed. The last few percentage points of automation can determine whether the economics work.
My hypothesis is that mature, standardized operations with sufficiently high straight-through processing rates can achieve 15–30% operating margins. Contribution margins exclude product development, sales and corporate overhead, so these are different measures. The attraction isn’t SaaS-style margins. It’s that a provider might earn attractive operating margins while capturing a much larger portion of the customer’s total spending on the process.
The profit opportunity comes from spreading the cost of building and controlling the operation across many customers, while keeping the incremental cost of execution and exceptions low.
Why this won’t simply commoditize
This is the obvious challenge to my argument. If model providers, hyperscalers and SaaS incumbents can all offer autonomous operations, why should any operating platform retain pricing power?
Some won’t. Routine, standardized work with low switching costs will face price competition, and providers that simply package an agent with a few APIs will struggle to defend margins.
The stronger positions are in processes where reliability is difficult to establish and failures are consequential. A provider that has handled millions of cases under agreed controls has evidence of competence, and replacing it means retesting controls and changing contractual responsibilities.
But reliability alone isn’t a permanent moat. The advantage comes from continuously improving the economics of execution while maintaining that reliability. A competitor may reproduce the technology. Matching the operating performance across thousands of exceptions, changing customer requirements and regulatory obligations is a different challenge.
What would prove me wrong?
I would reconsider in three cases. First, if conventional SaaS vendors retain their pricing power despite declining human usage, without assuming greater responsibility for business outcomes. Second, if general-purpose orchestrators capture most incremental enterprise automation profits. Third, if productized operating businesses fail to generate attractive returns after accounting for exceptions and liability.
If I ran a software company, I would ask three questions.
- Which parts of our revenue depend on users, which on transactions, and which on capabilities customers cannot easily replace?
- What decision rights would customers trust us to exercise, and what liability are we prepared to accept?
- Does our business become more valuable when our customers become more productive?
If the answer to the last is no, adding AI features won’t fix it.
For thirty years, software companies built great businesses by selling tools that people used to do work. The next generation will increasingly be built around taking responsibility for getting the work done.
