A portfolio company can keep its customers and still lose expansion revenue during a hold period. The problem starts when the company charges per user while more customer work moves to agents that use the product through APIs.
Seat pricing assumes that product usage grows with the number of people using the software. Agent-driven usage changes that relationship.
Research Grounding
On July 1, Gartner estimated that up to $234 billion of enterprise application software spending is exposed to agentic arbitrage by 2030, or roughly 20% of the market.
Gartner uses the term agentic arbitrage for work that AI agents complete across software systems through APIs without a person opening each application's interface. A customer can therefore get more work from a product without adding users.
On July 27, Gartner raised its 2026 worldwide IT spending forecast to $6.37 trillion, up 14.2%. Gartner expects software spending to reach $1.468 trillion, up 15.5%.
Software spending can continue to grow while the unit used to price software changes. For a SaaS company that relies on seat expansion, that creates a revenue-model issue rather than a demand issue.
The PE Translation
For a public software vendor, this is a competitive issue. For a PE-backed software company, the timing matters because a pricing-model change can affect valuation before it produces a visible revenue decline.
Bain's 2026 Midyear Private Equity Report puts the implied capital cycle at roughly seven years. Bain also reports that software valuations inside PE portfolios fell about 8% in Q1 2026 on MSCI's measure, including 8.9% in the US.
Bain's February Global Private Equity Report makes the return requirement harder as well. Bain describes the current environment as "12 is the new 5": a deal that once could have met return targets with mid-single-digit EBITDA growth may now require low-double-digit growth.
Bain also cites an ILPA poll finding that most LPs lose confidence in a GP when an exit prices more than 5% below the last mark. Software marks moved by more than that in a single quarter.
A software company purchased in 2026 may still be in the portfolio when Gartner's 2030 estimate plays out. The sponsor therefore needs to understand whether the company's current pricing model will still reflect how customers consume the product several years from now.
A buyer can test this before revenue materially declines. One useful diligence question is:
What is the ratio of API calls to UI sessions in the company's largest accounts, and how has that ratio changed over the last eight quarters?
If API usage rises while paid seats remain flat, customers are already moving work away from the interface. That will affect renewal discussions if the contract still prices the product primarily by user count.
Net revenue retention can weaken while customer retention remains stable. The company keeps the customer, but the customer has less reason to add seats.
As agents complete more of the workflow, the alternative may not be pure usage pricing. Some products may move toward hybrid models or pricing tied to completed workflows and business outcomes. The architecture has to measure those outcomes reliably before the commercial model can depend on them.
Operator Experience
Changing the pricing model is partly a commercial decision, but the product architecture determines how quickly the company can implement it.
I would look at five areas.
Metering
A company cannot charge for consumption or outcomes unless it can measure the billable unit accurately. That requires event-level usage data, reconciliation with billing, and enough history to reproduce an invoice when a customer questions it.
Many software companies already collect usage data, but application logs were usually designed for troubleshooting rather than billing. They may have short retention periods, incomplete event coverage, or no reconciliation with the billing system.
Building a billing-grade metering capability can take several quarters. Product teams also tend to deprioritize the work because customers do not see a new feature at the end of it.
For a company considering a pricing change, metering belongs in the value-creation roadmap because the pricing model depends on it.
Entitlement
Seat-based products usually authorize access against a human user. Permissions, audit records, rate limits, and row-level security may all depend on that user identity.
An agent acting on behalf of a customer creates a different requirement. The platform needs to represent a person, service account, application, or delegated agent and still enforce the correct access rules.
Changing that identity model can touch a large portion of the application. The board should know whether the current authorization model supports agent-driven usage before approving a pricing strategy that assumes it does.
API Coverage
Customers can only automate the workflows exposed by the API. Many mature SaaS products have broader functionality in the interface than in the API, because the API was added later for specific integrations.
I have shipped an API narrower than the product deliberately. The customer needed a defined integration, and expanding the API would have consumed roadmap capacity without additional revenue at the time.
That decision changes when customers begin using agents as a primary way to interact with the product. API coverage then affects how much of the product customers can automate.
The opposite problem also matters. Some APIs allow actions without applying all of the validation or approval logic used by the interface. Agent-driven volume can expose those differences quickly.
Cost to Serve
Agent traffic changes infrastructure usage. Human users create relatively limited request volumes. Agents can poll frequently, retry requests, and execute workflows across many accounts.
A customer can therefore generate significantly more infrastructure usage without increasing its seat count. A company using seat pricing needs to compare agent-driven API consumption with gross margin by account. Otherwise the existing contract may no longer reflect the cost of serving that customer.
Product Context
Outcome-based pricing only works if the product can produce an outcome the customer values.
That requires more than model capability. The product may need customer-specific rules, prior exceptions, approval history, configuration, and other operating context. In many companies, part of that context remains in support tickets, implementation notes, email, or the knowledge of long-tenured employees.
If the agent cannot access the context required to complete the workflow correctly, the company has limited ability to charge for the outcome.
A two-hour architecture review with the platform lead can identify most of these constraints.
Board Question
What percentage of our ARR is priced per seat against work that a customer could complete through an agent, and what would we need to change before we could price that work differently?
If the answer requires significant changes to metering, identity, API coverage, or cost controls, the pricing change needs to be included in the product and platform roadmap.
The METER Test
METER converts the architecture and commercial questions into five areas a board can review.

M: Metering
Can the company produce an auditable count of a billable unit other than seats and reconcile that count to an invoice today? If the team says it could build the capability, the current answer is no.
E: Entitlement
Can the authorization model represent people, systems, service accounts, and delegated agents while applying the correct access rules? The answer determines how much work the company must do before agent-driven usage can operate safely at scale.
T: Traffic
Track API calls per account against monthly active UI sessions over time. The trend matters more than the absolute number. An account with rising API usage and flat seat count is already shifting work away from the interface.
If the company cannot produce this data, that is part of the finding. The team will need to build or reconstruct the measurement before management can quantify the trend.
E: Exposure
What percentage of ARR comes from seat-based contracts covering workflows that an agent can perform end to end?
Calculate this at the contract level. The largest accounts usually deserve the first review because they represent the greatest revenue exposure.
R: Reprice
What would it take to change the pricing model at renewal? Assess the contract language, notice periods, procurement requirements, expected customer response, and the gross margin implications of moving from seats toward usage, completed workflows, outcomes, or a hybrid model.
A usage-based model can create a margin problem if the platform has not been optimized for the associated request volume.
METER gives the board two answers.
Exposure estimates how much revenue is affected. Metering, entitlement, traffic, and repricing readiness estimate how much work the company needs to do before it can respond.
The METER Test in one screen
M / METERING: Can we measure a billable unit other than seats?
E / ENTITLEMENT: Can identity represent a person, system, service account, or delegated agent?
T / TRAFFIC: How are API calls per account changing relative to UI sessions?
E / EXPOSURE: What percentage of ARR is tied to seat-based contracts for workflows agents can automate?
R / REPRICE: What contract changes, platform work, and gross-margin assumptions are required to change the pricing model?

Three Decisions
1. Run METER on the top twenty accounts by ARR before the next board meeting.
Review each account's contract, seat count, API traffic, UI activity, and automatable workflows. The result should be an estimate of ARR exposed to changes in how customers use the product.
2. Fund metering and identity work based on the exposure.
If METER shows material exposure and the platform still depends on seat-based identity and application logs for usage data, treat the required platform work as part of the value-creation plan. Give the work an owner, budget, roadmap date, and expected commercial outcome.
3. Add two questions to technical diligence.
For software deals, ask how API traffic has changed relative to UI activity in the largest accounts, and whether the authorization model supports users, systems, service accounts, and delegated agents.
These questions help the investment team estimate how much pricing flexibility the platform currently supports.
One Number for the Next Operating Review
20%. Gartner estimates that roughly one-fifth of enterprise application SaaS spending could be exposed to agentic arbitrage by 2030.
The portfolio company's own number is more useful. Ask management to calculate the percentage of ARR tied to seat-based contracts for workflows that agents can automate. Then compare API activity with UI activity for those accounts.
That gives the board a starting point for deciding whether the current pricing model needs platform investment during the hold period.
Board Takeaway
Seat pricing works when the number of users remains a reasonable proxy for the value customers receive. Agent-driven usage weakens that relationship.
Management should measure where API activity is replacing human interaction, determine how much ARR is exposed, and decide whether the platform can support another billing unit before the issue reaches renewal discussions or buyer diligence.
Portco Brief is a weekly briefing for PE operating partners and portfolio company executives focused on technology, AI, and value creation. If this was forwarded to you, subscribe at portcobrief.com.
Sources
Gartner, "$234 Billion in Enterprise Application Software Spend Is at Risk from Agentic AI", July 1, 2026.
Gartner, "Worldwide IT Spending to Grow 14.2% in 2026, Totaling $6.37 Trillion", July 27, 2026.
Bain & Company, Private Equity Midyear Report 2026, June 2026, and the Global Private Equity Report 2026, February 2026.
Software valuation data attributed by Bain to MSCI. LP confidence data attributed by Bain to ILPA.

