Image source: Pixabay.com/Placidplace
TL;DR
- Unlike traditional SaaS, AI agents deliver uncertain value at a cost that keeps shifting, and that combination breaks the pricing logic SaaS was built on.
- Every pricing model on the market today is a bet on a different definition of value, and each bet creates its own unit-economic problem.
- Your pricing metric dictates what you have to monitor internally. Most teams build these two things separately.
- A product that looks profitable in aggregate can lose money on a specific feature. We found one that had been losing money for months, and fixing it saved roughly $800K a year.
The better a customer support agent gets at knowing when to hand a case to a human, the less its vendor may earn from that conversation. It's one of the odder side effects of how AI agents are priced today, and it says a lot about how unsettled the market still is. One vendor charges per resolved ticket, another bills per conversation, a third is still clinging to seats, while others build raw margins from the underlying LLM cost up.
Nobody has actually figured this out. Part of that is how young the category is. Most of it is that the delivered value is uncertain, not deterministic as in a regular SaaS business, and the cost isn't stable either. The problem is sharpest for conversational agents handling customer support and sales, where a single interaction has a clear outcome. Coding agents and background automation carry their own pricing problems, but the resolution-versus-escalation tension is specific to agents that talk to customers.
Why nobody agrees on what value means
Customers describe what they're paying for in very different terms. A team that lives by response times wants tickets answered fast. Another cares mostly about whether the answer was actually right, and some see the agent as a way to avoid the next support hire. Put two of those customers in front of the same agent and they can reach opposite conclusions about whether it works.
Add unpredictable, per-interaction LLM costs to that mix, and you get the current spread of pricing models. Every pricing page today is essentially a bet on which definition of value will win out.
What each pricing model is betting on
Resolution-based billing bets that a closed ticket is the clearest proxy for value. Customers pay only when the agent solves the problem on its own. It is a clean ROI story, but the incentive can point the wrong way, pushing the system to close tickets rather than actually solve them. And every time the agent correctly escalates a complex case to a human, the vendor loses the revenue on that ticket.
Conversation-based billing charges for every ticket the agent touches, whether it ends in a resolution or not. That takes the escalation problem off the table: the vendor gets paid either way, so there's no reason to push for a resolution that isn't really there. It also helps customers budget, because conversation volume is much easier to forecast than a resolution rate nobody can predict in the first month. The harder part is that the model assumes every conversation was worth something, including the ones handed to a human. Sometimes that's easy to show, when the agent has already pulled the account details and order history a person would otherwise spend ten minutes chasing. Sometimes it's a much harder case to make.
Cost-plus pricing starts from what the vendor spends on LLM calls and adds a margin on top. It feels like the responsible choice, and it runs into trouble in two places. It has nothing to say about value, so a product that saves a support team six figures a year ends up priced off inference cost, and most of what that customer would happily pay stays on the table. And the cost it's built on doesn't sit still. A new feature can double token usage within a week, and a model update can cut it just as fast, so the price keeps resting on a number that's already out of date.
Seat-based pricing carries a familiar SaaS habit into a product it doesn’t fit. It’s predictable and comfortable for sales teams, but it tracks how many people have access rather than what the agent actually does.
None of these models is wrong as such. Each one is built around a different idea of value, and each one creates its own unit-economic problem.
Why the pricing metric decides what you monitor
Pricing usually gets discussed as a sales and marketing question. What gets less attention is that the pricing metric also determines what you need to track internally to stay profitable.
I work on pricing for an AI agent product that bills per resolution, so the number I watch most closely is what each resolved ticket actually costs:
Cost per resolution = total LLM spend / resolved tickets
Most attention goes to the top of that fraction, and the bottom is where the trouble starts. If the resolution rate slips while token spend stays where it was, every resolution gets more expensive. Average cost per conversation stays flat, though, and the infrastructure dashboard gives no sign that the margin is getting thinner.
That's why, for us, resolution rate matters as much for margin as it does for product quality. A vendor billing per conversation doesn't carry this risk, because their denominator is conversations, and those are much easier to forecast. Two companies can run the same models on the same infrastructure and still need to watch different numbers.
Where the cost actually hides
These problems hide in aggregate numbers. Each LLM-backed feature has its own model, prompt length, and call pattern, so you need to track its cost and billing rate separately. A feature can look profitable in aggregate and still lose money within its own cohort.
Model choice matters just as much, and context size can grow fast over the course of a conversation, so the same feature can cost very different amounts depending on how the conversations it handles actually go.
The feature that was losing money for months
Last year I ran into exactly this at work. We were tracking cost per resolution, prompt costs, resolution rates, and a lot of other cost and performance metrics closely. Everything looked fine at the aggregate level. Still, I suspected one of our LLM-based proactive features was costing more than it returned.
So I isolated the tickets originating from that feature and looked at them on their own. We’d been losing money on it for months. It was the same metric we’d been watching all along, just looked at across a narrower cohort.
We moved that feature to a smaller LLM model, and that optimization alone saved us roughly $800,000 a year.
Building pricing and monitoring together
I’m not going to recommend a model here. Resolution-based billing makes the most sense for what we build, and it still comes with every tradeoff described above. Anyone claiming to have the ultimate AI pricing playbook probably hasn’t talked to enough buyers with conflicting incentives.
I recommend a specific order of decisions. Talk to customers about the value they actually experience, not the value you’d like to be delivering. Pick the pricing model that best reflects what they tell you, even if it’s imperfect. Then build cost monitoring around that model from day one, instead of treating it as a separate track to sort out later.
Pricing strategy and cost monitoring have to be built together. When you build them in silos, you end up with surprising unit economics and a leak that shows up only when someone goes looking for it.