A software rebound cannot settle the AI displacement question
Market recovery is an outcome with many causes. Vendor diligence needs a direct test of how agent activity reaches the bill, rather than treating share-price moves as proof.
A recovering software index does not run an experiment on AI displacement. Neither did the selloff that preceded it.
Jason Lemkin’s September 4 review of software winners and losers argues that billing exposure and starting valuations help explain the dispersion. He points to consumption businesses that can earn more as AI creates additional queries, traffic and monitoring work.
That is a useful business-model hypothesis. It is not a causal decomposition of every share-price move, and a pair of companies with similar revenue growth does not become a controlled natural experiment. Their other characteristics still differ.
The claim I would take into procurement is more practical: an AI feature roadmap tells us what a vendor may deliver; its billing model tells us which changes in our behavior it has an incentive to encourage.
Map one agent task to the invoice
Suppose an assistant replaces several manual steps but generates more API requests, stored data and diagnostic events. Different suppliers can experience that same workflow as lost seats, higher consumption or no immediate billing change.
That difference matters to both sides of the contract. A vendor whose meter captures additional workload may have an economic reason to support it. A buyer may discover that a productive automation expands a bill that was previously stable.
Neither result proves the software is safe from competition. A consumption product can lose workloads to a substitute. A seat-based product can change its pricing or retain value through functionality and trust. The contract is a starting point for analysis, not a permanent ranking of winners.
I would avoid treating the stock market’s answer as a substitute for this inspection. Price reflects expectations and many influences we cannot isolate from a chart. The invoice gives us a more direct mechanism to test.
Run the workload through two budgets
For a hypothetical enterprise rollout, I would ask the team to estimate the current manual workflow and the proposed agent workflow using the same business volume. Keep the number of customer cases fixed, then identify the billable events each approach creates.
Does an agent count as a user? Are tool calls, messages or database operations charged separately? Does a retry generate another unit? Which logs are mandatory, and which are optional? What happens when the vendor introduces an AI-specific allowance or minimum commitment?
I would then run a second scenario with higher business volume. This separates the cost of changing how work gets done from the cost of doing more work. Without that separation, a successful rollout can look inefficient merely because demand grew, or look efficient because usage stayed artificially constrained.
The output should be a budget range and a list of contract assumptions to confirm. It should not be a prediction of the vendor’s share price.
There is a strategic question here too. If the vendor’s financial incentive depends on more activity, I would ask how its product helps eliminate unnecessary activity. A system that saves employee time by generating avoidable paid work elsewhere may still be worthwhile, but the trade deserves measurement.
Lemkin’s billing lens is worth carrying forward. The stronger claim that a market rebound has resolved the displacement debate can stay behind.
Follow the agent’s work into the invoice; a share-price recovery cannot tell you who gets paid for it.
