Pricing a New AI Capability With No Competitor Price to Copy

TL;DR

When a software company sets out to price a new AI capability and no competitor publishes a price, the pattern we see most runs in four steps. Find a comparable, read the usage logs, borrow a rate, and size the revenue against the core contract. Every step measures consumption or someone else’s value, so the sequence drifts away from the buyer at each move. The question that belongs first is what the new capability does to the unit the existing contract already counts.

The four steps we see when a category prices its first AI capability

A vendor adds an agent, an API, a model-backed feature or a machine access path to a product that has always been priced on people. Nobody in the category has priced one yet. Across our pattern library, the analysis that follows takes the same order, and the order is the problem.

The first step is the comparable. Someone searches for a vendor that charges for something resembling the capability. The category has none. So the search leaves the category and keeps going until it finds a published rate.

The second step is the usage logs. The team pulls telemetry on who calls the capability, how often, and in what rhythm. The logs are complete and current, which makes them the most trusted input in the room.

The third step borrows a rate. The published price from the comparable is attached to each candidate meter, the count the capability would be billed on: per call, per record, per task, per account. Each candidate now has a number beside it.

The fourth step sizes the revenue. Each candidate is multiplied through the logs and the total is compared with the value of the core contract. The total comes out absurdly small or absurdly large, or it rests on a handful of early users and nobody trusts it. Either way the recommendation is to fold the capability into the contract that already exists.

Every step is defensible on its own. The sequence has no step for value, and it never asks what the capability does to the AI software pricing architecture the product already runs on.

Why the comparable hunt moves away from your buyer

No competitor publishes a price, so the search for one widens outward in steps. The first hop lands on data vendors that meter rows returned. The next lands on agent vendors that charge per resolution. The next lands on infrastructure blogs that quote per-call ranges. Each hop is further from the person who budgets for your product.

Each of those vendors sells to a different buyer, carries a different cost base, and displaces different labor. Per-resolution prices read as anchored to the labor the agent vendor’s product replaces at its customer, which is the comparison its buyer is making. In the capabilities we see added to existing products, most displace nobody. They extend what an existing user already does with the product, so a rate anchored to replaced labor describes value your buyer never receives.

What a comparable does transfer is its unit. The unit encodes what that vendor’s buyer recognizes as value received, and a buyer in an adjacent market may recognize value in a similar count. The rate encodes that vendor’s cost structure and market position, and neither of those is yours. Read a competitor’s page for the unit it chose and the reason the buyer accepted it. Reading a competitor’s pricing page on its own terms is a discipline of its own, and the rate is the one line to leave on the page.

What the usage logs can and cannot tell you

Usage telemetry is a complete record of consumption. It shows who calls the capability, how often, in what pattern, and how concentrated the volume is. It is an empty record of value. No log line records what the customer did with the result or what the result was worth to the person who approved the budget. An analysis built on logs can size every candidate meter and validate none of them.

Two reads from the logs do carry pricing information. The first is the split between human and machine use. When an AI agent acts for a person at a desk, its calls follow that person’s day. They go quiet at weekends and over holidays. A scheduled integration does not.

The rhythm tells you whether the capability is being used as an extension of a seat or as a standing process, and those are different units.

The second read is concentration. A handful of integrations can account for most of the volume, and each of those integrations is someone else’s code. A retry loop, a polling interval, or a batch job rewritten by a customer’s engineer moves the meter without any change in value delivered. A meter chosen for revenue inherits that volatility, and the vendor neither controls it nor earned it. Ask what happens to the revenue line if the heaviest integration rewrote its retry logic tomorrow.

Why the revenue test is the wrong way to price a new AI capability

The fourth step is the one that decides. Each candidate meter is multiplied against the logs and the totals are lined up beside the size of the core contract. The capability’s revenue comes out absurdly small or absurdly large next to it, or it rests on a handful of early users. Bundling follows. Bundling can be the right answer, and the arithmetic is the wrong reason for it.

Look at what each column in that table contains. Volume is firm. It was measured. The rate in every row was borrowed from a vendor whose buyer is different from yours, so the total is measured volume multiplied by someone else’s price. The comparison with the core contract carries the same borrowed rate forward.

A small result tells you the borrowed rate was small. It says nothing about whether to meter the capability at all.

The cost floor is the other borrowed anchor that appears at this step, and it fails the same way. Inference cost tells you where the price cannot go below. It has nothing to say about where the price should sit.

A vendor opened a machine access path to a product priced on seats and a share of the customer’s spend, and set out to price the access. The usage logs showed the heaviest accounts were single users running integrations. The analysis multiplied each candidate meter against the logs, compared the total with the size of the core contract, found it small, and recommended folding access into the contract that already existed. The question the analysis never asked was what a one-user integration does to the seat count once that pattern spreads across the customer base.

That vendor held the consumption half of the pricing decision in full. The value half, what the customer’s budget owner recognizes the access as and what they would agree to count, was missing from every row of the table.

Start here: what the new AI capability does to the unit you already count

A new AI capability reaches the customer in one of two ways. It is a new path to value the customer already extracts from the product, or it is value the customer has never drawn from the product before. In either case it meets the existing contract’s unit before it meets any new price, because the customer is already paying in that unit. That unit is the value metric, and the first pricing exposure is a change in what it counts. Three places the exposure hides.

Seat exposure: one integration where many logins used to be

A product priced on seats counts people. A machine access path lets one integration account do the work that many logins used to do. The customer receives the same value, or more, and the seat count falls. The contract still describes the customer accurately on the day the integration ships and stops describing them as the pattern spreads.

Seat counts under agentic usage have their own mechanics. The exposure to name here is that the unit moved before the price did.

Allowance exposure: a pool sized for a different use

Many contracts carry an allowance, a pool of the metered unit included with the subscription and sized for how people use the product. A new capability that draws on the same pool changes what the pool is for. The customer sees nothing new on the invoice while the allowance is consumed by work it was never designed to cover. Ask what the pool was sized against, and whether the new capability consumes it in the same way.

Gateway exposure: the vendor’s agent and the customer’s agent

The vendor ships its own AI agent inside the product. The customer connects its own agent through a machine access path such as a Model Context Protocol (MCP) server. When both reach the same tools through one gateway, the same piece of work can be counted in two units. The vendor’s agent is counted in whatever its feature is priced on, and the customer’s agent in whatever the access path meters.

The capability’s price cannot be settled until the two streams are separated. The MCP-specific access shapes are the worked case of this pattern and are covered there.

When bundling a new AI capability is the answer, and when it postpones the decision

Bundling the capability into the existing contract is right when the current unit already captures the value the capability adds. When the feature helps a seat holder do the same job faster, that seat holder is still the one consuming it, and the seat already carries the price. The invoice keeps describing what the customer receives.

Bundling postpones the decision when the unit is changing under it. If one integration replaces a floor of logins, the seat has stopped counting what the customer receives. Folding the access into the seat contract postpones the decision to a renewal where the customer already has fewer seats to buy. The same small revenue figure supports both readings, and nothing in the figure says which one applies.

The tension resolves with one question put to the customer base: if every account adopted the capability the way the heaviest one has, would the invoice still describe what they received? Who should make that call is a decision of its own. The people who own the logs can supply more measurement, and more measurement is the half the decision already has.

Making the call

The telemetry-led process skips one decision, and it is the one that sets the price: the value question. No log answers it. More measurement produces a more precise record of consumption and leaves the value column empty. The missing half comes from a value read of the customer. How does the budget owner recognize the capability, what would they agree to count, and does the unit on the contract still describe what they receive once the capability is in use?

A Pricing Ground Truth engagement supplies that half. The vendor brings the consumption half, which is usually complete, and our pricing experts bring the value half from the customer read. Together they settle whether the capability is a path into an existing unit, a new unit, or a reason to re-cut the existing one. If you are partway through the four steps and the table already says bundle, talk to a pricing expert before the renewal cycle makes the decision for you.

FAQs