Per-seat vs volume pricing for AI agents (and why we chose volume)
Per-seat pricing made sense for SaaS that automated individual work, Notion, Figma, Slack. The unit economics line up: more seats means more value, and the customer's willingness to pay scales with seats.
Per-seat is the wrong model for AI agents. The whole point of an AI agent is to take work off the headcount line. Charging per seat punishes the customer for the outcome they hired you to produce.
The unit-economics problem
Suppose you have a tier-1 ticket triage workflow that handles 10,000 tickets a week. Pre-agent, that took 12 reviewers. Post-agent, it takes 4. A vendor charging per seat sees revenue drop by two-thirds, even though the customer is getting more value, faster.
The vendor's incentives are immediately misaligned. They will price floor seats. They will define seats expansively (everyone who touches the queue is a seat). They will not invest in features that reduce the supervisor count, because reducing the supervisor count reduces revenue.
Why volume pricing works
Volume pricing, pricing per decision made, per claim adjudicated, per ticket resolved, aligns the vendor with the customer. We make more money when the customer pushes more volume through the agent. The customer pays more because they got more done, not because they hired more people.
It also produces clean SLAs. "We will resolve up to N tickets per month at X price, with a confidence threshold of Y." Both parties understand exactly what they are getting and exactly what they pay.
The token-bill problem
A common counter is: "But your token bills will eat the margin." This is the third-vendor pricing model, pass-through token costs. It is the worst of the three.
Pass-through pricing means the customer's bill is unpredictable, the vendor's incentive to make the agent efficient evaporates, and the procurement team has to learn what a token is to evaluate the deal. We have never seen this model work for a serious enterprise sale.
The right answer is volume pricing where the vendor absorbs token costs and is incentivized to optimize them. The customer gets a predictable bill. The vendor gets a margin lever. Both parties agree on what value looks like.
What we charge for
We charge per decision the agent processes, with tiered SLAs, capped supervisor queue support hours, and a no-per-seat clause in the contract. The procurement team can evaluate the deal as a unit-economic question. The ops team can plan capacity as a volume question. Engineering does not have to learn what a token is.
That is the math behind why we chose volume. It aligns the incentives, it produces a predictable bill, and it does not punish customers for the outcome they came to us for.