Outcome-Based Pricing for AI Agents: How to Charge Per Outcome Without Losing Money

Short answer: Outcome-based pricing for AI agents charges the customer only when the agent completes the job, so a failed or escalated task bills nothing. Intercom publishes 99 cents per outcome for Fin. Zendesk bills on automated resolutions and Sierra negotiates a per-outcome rate inside each contract, neither publishing a rate. The model wins deals because the buyer carries no risk on failure, and it fails on margin when a minority of hard cases cost more to serve than they bill. Two things make it survivable: a definition of success a customer would sign, and a hard ceiling on what the agent may spend chasing one outcome.

This is the pricing question almost every agent company is arguing about right now. It is worth separating what is genuinely new from what is a rerun of the usage-based pricing debate with a better name.

What is outcome-based pricing for AI agents?

Outcome-based pricing charges for a completed result rather than for access or effort. A support agent bills per resolved conversation, not per message. A sales agent bills per booked meeting, not per email sent. A claims agent bills per adjudicated claim, not per document read. The unit is whatever the customer was actually trying to buy, which is why buyers find it easy to approve: they are paying for the thing on the business case rather than for the machinery underneath it.

The mechanical difference from usage-based pricing is where the failure risk sits. Under usage pricing, a task that runs, consumes tokens and produces nothing useful still bills. Under outcome pricing, the vendor eats that cost. That single shift is the entire commercial argument, in both directions.

What AI agent vendors actually charge per outcome

Published rates in this category are scarce, and who publishes tells you as much as what they publish.

Pricing as published on each vendor page in August 2026. Two things stand out. First, the self-serve products publish and the enterprise products do not, which is a sales-motion decision rather than a philosophical one. Second, Salesforce, the largest vendor in the group, deliberately did not go outcome-based. It meters actions instead, because an action is unarguable and an outcome is negotiable, and at Salesforce volume the disputes would be expensive. That is a real signal, not an oversight.

Why buyers pull for outcome pricing, and why that should make you careful

The buyer case is genuinely strong. Zero results means zero invoice, which removes the pilot risk that kills most agent deals. It converts an unproven technology purchase into a variable cost with a clear unit story, which is exactly what a CFO wants to approve. And it forces the vendor to carry some risk on quality.

The reason to be careful is that the same properties transfer risk onto your income statement. You are now underwriting the difficulty of your customer workload, which you do not control and cannot fully see before you sign. A support agent priced per resolution against a clean, well-documented knowledge base has a very different cost of service from the same agent pointed at a sprawling legacy help center. Same price, different margin, and you found out after the contract was signed.

Kyle Poyar surveyed more than 230 software companies between April and May 2026 for the State of B2B SaaS and AI Monetization report. Hybrid pricing, a base fee plus metered consumption, rose from 25 percent of respondents twelve months earlier to 37 percent. Asked what investors would prefer, 26 percent said outcome-based and 35 percent said hybrid. Read that as the market landing where it usually does: outcome pricing as a component, with a floor underneath it, rather than as the whole model.

How do you define an outcome for an AI agent?

Write one sentence a customer would sign before they see the invoice. If you cannot, you are not ready to charge for it. Intercom publishes its definition precisely because outcome disputes are the failure mode of this model. Work through four questions in order.

1. What observable event proves success? Prefer something the system records on its own. A customer clicking a confirmation is stronger evidence than an internal classifier deciding the answer was good.
2. What happens on a partial result? If the agent handles two of three questions in one conversation and hands off the third, does that bill? Intercom answers this by billing once per conversation and counting a completed procedure including handoffs.
3. What happens on a repeat? If the customer comes back an hour later with the same issue, was the first outcome real? Most workable definitions include a lookback window and do not bill twice inside it.
4. Who adjudicates a dispute, and against what record? You need immutable event logs carrying the agent, the customer, the task and the timestamp, kept long enough to defend an invoice four months later.

Answer those four and you have a pricing policy. Skip them and you have a support queue full of billing arguments, which is a worse business than the one you started with.

The margin trap: the heavy tail nobody models

Here is the arithmetic that catches teams. Suppose you price at 99 cents per resolution and your average resolution costs 22 cents in model tokens, retrieval and tool calls. That is a 78 percent gross margin and a good business. Now split the traffic. Eighty percent of conversations resolve in two turns at about 9 cents. Fifteen percent take five or six turns at around 40 cents. The last five percent are the ugly ones: long transcripts, repeated retrieval, several tool calls, sometimes a lookup you pay a third party for, landing anywhere from a dollar to several dollars. Weight those and the blended margin still looks fine, right up until a customer arrives whose mix is thirty percent ugly cases. That account is unprofitable while your dashboard shows revenue growing.

Averages hide this because agent cost distributions are not normal. They have a long right tail, and outcome pricing sits directly on top of it, because the hardest cases are the ones the agent works longest on and is least likely to resolve. You pay twice: the compute on the failures, and the discount on the successes.

The consequence extends past the P&L. Revenue quality gets scrutinized later too, and buyers who price AI SaaS off verified metrics will discount revenue whose gross margin swings with model versions and customer mix. Knowing your cost per outcome by customer is not just an operating nicety, it is part of what the business is worth.

Cap the spend per outcome, not just the price

The fix is a ceiling on what the agent may consume chasing a single outcome, enforced before the spend happens rather than reported after it. In practice that means a per-task budget covering model calls, tool calls and any purchase the agent makes, with three behaviors at the boundary: stop, escalate to a human, or continue under an explicit override. A task that has already burned three dollars against a 99 cent price should not be allowed to keep going quietly.

This is why we treat hard spend limits as a pricing feature rather than only a security one. The same mechanism that stops a runaway agent also protects the unit economics of an outcome price, and the same audit trail that satisfies your auditor is what produces cost per outcome broken down by agent and by customer. Most teams charging per outcome cannot produce that number on demand, which is precisely why they find the heavy tail late. The broader picture, including the other five pricing models and the rails that collect them, is in our guide to AI agent monetization, and the fee side of the equation is covered in what AI agent payment infrastructure costs.

When outcome-based pricing is the wrong choice

Four cases where you should not use it, at least not on its own.

• The outcome is ambiguous. Research, drafting, analysis and anything creative do not have a clean success event. Charge for the work or for access.
• The customer controls the success rate. If a thin knowledge base or dirty data caps what the agent can resolve, you are underwriting their operations. Price the floor high enough to cover it, or sell the cleanup first.
• Volumes are small. Outcome pricing needs enough events for the averages to behave. At ten outcomes a month, one weird case is the whole month.
• Cost per outcome is unbounded. If an agent can call a paid API an unlimited number of times, cap it before you price the outcome, not after.

In every one of those cases the answer is usually hybrid: a platform fee that covers the fixed cost of serving the account, plus outcome pricing on the one workflow where the result is beyond argument. That is where most of this market is landing, and it is a more defensible pricing page than a single heroic number.

Is outcome-based pricing better than usage-based pricing?

Neither is better in the abstract. Outcome pricing sells more easily and shifts execution risk onto the vendor. Usage pricing protects margin and shifts forecasting risk onto the buyer. The practical question is whether you can define success unambiguously and cap the cost of pursuing it. If you can do both, outcome pricing is a strong commercial weapon. If you can do neither, it is a way to grow revenue and lose money at the same time.

Start by instrumenting the events and running the meter in shadow mode against real traffic for a few weeks. Look at the cost distribution rather than the average. Then set the price, and set the cap in the same meeting.