You have built an agent that resolves support tickets, or qualifies leads, or closes the books, and now you have to put a number next to it. The instinct is to copy whatever your category already does — so you reach for the per-seat price sheet that every SaaS company has used since 2010. That instinct is the trap. Per-seat pricing assumes the thing you sell costs you nothing to run. Your agent does not have that property.
Here is the one idea worth carrying through every pricing meeting: the model you pick is a decision about who absorbs the inference bill. Traditional software has near-zero marginal cost — the ten-thousandth user costs about what the first one did, which is how pure SaaS posts gross margins north of 80%. An agent pays an LLM every time it runs. That payment is a variable cost of goods sold, a line item that scales with use, and it does not go away no matter how you label the invoice. Every pricing model below is just a different answer to the question whose problem is that cost.
Per-seat: you eat the variance#
Seat pricing is a flat fee per human login. It is the easiest to sell because buyers already understand it and the invoice is predictable. The problem is structural and it is fatal: you are charging a fixed price for a thing with a variable cost. If a heavy team works the agent hard one month, your margin on that seat compresses; if the underlying model price spikes, you eat it.
Worse, the seat is the unit you are trying to destroy. An agent that genuinely replaces human work shrinks the number of seats the buyer needs. You cannot build a growth model on selling more of the exact thing your product eliminates. This is why a16z argued back in December 2024 that AI is pushing enterprises off per-seat pricing entirely — the seat-counting buyer is a shrinking population.
Per-usage: the buyer eats the variance#
Flip it around: charge per token, per action, per "credit." Now your revenue tracks your cost almost perfectly, and your margin is protected by construction. Salesforce's Agentforce is the cleanest large-company example — it now bills $0.10 per action (20 Flex Credits, sold in packs of 100,000 for $500), having moved off an earlier flat $2-per-conversation model in May 2025.
The cost of usage pricing is paid in trust. You have handed the buyer a meter they cannot predict and do not control, and the one thing procurement hates more than a high bill is a surprising one. Usage pricing turns every power user into a budget risk and every renewal into an argument about a number nobody forecast. It optimizes your margin and taxes your buyer's nerves.
The unit you price on is a confession about who you trust to absorb risk: yourself, your buyer, or your own eval numbers.
Per-outcome: whoever mispriced the outcome eats the variance#
Outcome pricing is the model everyone is excited about, and for a real reason — it aligns the bill with value. You charge per job done: a resolved ticket, a qualified lead. The anchors are now public. Intercom's Fin charges $0.99 per resolution (on a $49/month base that includes the first 50). Zendesk charges $1.50 per automated resolution on committed volume, $2.00 pay-as-you-go, where a "resolution" is a ticket the customer doesn't reopen inside roughly 72 hours. Sierra and Decagon sell on resolution too, though they negotiate the number privately.
This looks like the buyer-friendly answer, and it is — but read where the risk actually moved. You are no longer paid for running; you are paid only when the agent succeeds. That means you absorb the cost of every failed attempt, every retry, every multi-step trajectory that burned tokens and resolved nothing. The variance didn't disappear. It migrated onto whichever side got the per-outcome price wrong.
And that is the non-obvious part. The floor under any outcome price is the fully-loaded cost of producing that outcome — the inference for the successful run plus the inference for all the failed runs amortized across the wins. If your agent resolves 60% of tickets and each attempt costs you a nickel in tokens, your true cost per resolution is the math on that whole distribution, not the cost of one happy-path call. Price below it and you lose money on volume — the worse your agent, the faster you bleed.
So outcome pricing collapses two questions that teams usually keep in separate rooms. What do we charge per resolution? and what is our resolution rate and cost-per-attempt? are the same question. You cannot set the first number safely without instrumenting the second. A team that can't measure its agent's success rate and cost per attempt is not ready to price per outcome — it's gambling that its agent is good enough, with the inference bill as the stake.
What this means for the number you pick#
None of the three is "correct"; each one routes the variable cost somewhere. The reason most serious teams converge on a hybrid — a platform fee for predictability plus a usage or outcome meter for the variable part — is that the hybrid lets you split the risk instead of dumping all of it on one party. The platform fee covers your fixed cost and gives the buyer a number they can forecast; the meter covers the inference that scales.
But before you draw any line on the sheet, do the arithmetic that the whole industry's margins are quietly warning you about. ICONIQ's 2026 snapshot puts scaling-stage AI B2B gross margins around 52%, with inference eating roughly 23% of revenue — a world away from the 80%+ that pure software takes for granted. That gap is not a temporary inefficiency you'll optimize away with a better prompt. It is the permanent cost of selling something that thinks every time it's used. Price like you'll be paying that bill forever, because you will be.



