AI agent pricing is fragmenting across four models, each hiding a different economics story underneath. Your vendor's pricing model determines whether you budget like SaaS (flat monthly seat), utilities (per transaction), insurance (per outcome), or something entirely new. Understanding the models matters because two vendors billing the same $50,000/month can generate radically different cost-per-resolution numbers depending on whether they charge by the conversation, by the successful ticket close, or by a guaranteed outcome.
Per-Seat Pricing: The SaaS Baseline
Per-seat pricing is the legacy model: you pay a monthly fee per "agent" running in your environment, similar to how you'd license Salesforce seats. The vendor bills you $X/month for agent #1, $X/month for agent #2, and so on. This model appeals to CFOs because the cost is predictable—you know in January that agent budget will be $120,000/year—but it decouples cost from actual work performed.
The risk is that a low-volume seat (an agent handling 20 tickets/month) and a high-volume seat (an agent handling 200 tickets/month) cost the same. Intercom's legacy AI pricing was per-seat; many internal Slack bot deployments are still per-seat. The model works if your agents are intentionally oversized relative to demand, but breaks down in high-volume contact centers where a busy agent (and a quiet one) have identical licensing cost.
Per-seat pricing is fading because it rewards vendors for deploying fewer, more capable agents rather than many specialized ones. A vendor on per-seat can't afford to sell you five narrow agents (one for billing inquiries, one for refunds, one for account updates, one for escalations, one for retention) because you'd pay 5x the seat fee. Instead they push monolithic agents, which often perform worse.
Per-Conversation Pricing: The Utility Model
Per-conversation pricing charges you a fixed fee—say $0.50—for each distinct conversation the agent participates in, regardless of length or outcome. Decagon has used this model; some real-time agent deployments on Slack or Teams use per-conversation billing. The advantage is simplicity: you pay for what you use, and cost scales proportionally with agent activity.
The hidden cost is that "conversation" is vaguely defined. Does a 30-second back-and-forth and a 45-minute multi-turn debugging session both cost $0.50? Do retries (when the agent runs the same query twice) count as one conversation or two? If your customer replies to a chat three times and the agent responds three times, is that one conversation or six? Most vendors define conversation narrowly (one customer-initiated interaction = one conversation), but the boundary is easy to game.
Per-conversation pricing incentivizes vendors to limit agent turns and keep conversations short. If a vendor charges $0.50/conversation, their incentive is to resolve (or close) the conversation quickly, even if a second turn would serve the customer better. It works well for transactional agent use cases—"look up my order status" (one turn, one conversation) generates one $0.50 charge. It breaks down for advisors and problem-solvers, where depth of engagement is a feature, not a bug.
Per-Resolution Pricing: The Outcome Model
Per-resolution pricing charges only when the agent actually resolves the customer's problem—not per attempt, not per conversation, but per successful closure. Intercom Fin uses this model: you pay $0.99 per resolved support ticket. Sierra charges around $1.50 per resolution. The vendor bears the risk: if the agent fails to resolve the issue and the customer escalates to a human, you pay zero.
This model aligns vendor incentives with yours. A vendor on per-resolution pricing wants your agent to resolve tickets because they only get paid if it does. The vendor's gross margin depends on their cost-to-achieve-resolution being lower than $0.99 (for Intercom) or $1.50 (for Sierra), which means they're incentivized to:
- Deploy aggressive retry logic (call the API multiple times if needed).
- Train deep, domain-specific agents (healthcare insurance agents perform better than generic ones).
- Use expensive reasoning models if the extra reasoning improves resolution rate.
The visible cost per ticket ($0.99) is easy to budget. But the model requires you to define "resolution." Does a refund issued automatically count as resolved? Does "customer received a discount code and left satisfied" count, or only paid refunds? Does "customer was transferred to the right department" count as resolved?
Most per-resolution vendors define resolution narrowly: "the customer's original request was fulfilled." This creates a gray zone in your support taxonomy. If 2% of your tickets are actually mis-routed escalations that shouldn't count as failures, the $0.99 base cost starts to look cheap compared to the operational cost of managing the definition itself.
Per-resolution also hides long-tail cost. If 92% of tickets are resolved at $0.99 but 8% require retries, extra API calls, or escalation review, your blended cost per attempted ticket might be $1.20 even though the published rate is $0.99. This mirrors insurance: the quoted premium ($X/month) doesn't tell you the true cost after deductibles and exclusions.
Outcome-Based Pricing: The Insurance Model
Outcome-based pricing ties the agent's fee to a quantified business outcome, not just to task completion. Sierra's more recent deployments have begun experimenting with outcome-based models: instead of "$1.50 per resolved ticket," you might see "$0.15 per resolved ticket that prevents a customer churn event" or "$2.00 per claim adjudicated at 99%+ accuracy."
This model is the rarest because it requires the vendor to hold real P&L risk. If your AI agent resolves 100 support tickets, but each resolution creates downstream customer dissatisfaction (because the agent refunded when it should have offered a discount), outcome-based pricing would penalize the vendor even though the raw resolution count was hit. It's appropriate for high-stakes domains: claims processing (where accuracy matters), loan origination (where default rates matter), compliance (where missed risk matters).
Outcome-based pricing typically comes with a higher base cost per unit (Sierra's outcome variant might be $2.50 per claim instead of $1.50) but lower expected total cost because the vendor eats the cost of poor outcomes. Very few vendors use pure outcome-based pricing; most use a hybrid (per-resolution base + outcome premium).
Comparing the Models: A Quick Matrix
Consider a support center processing 10,000 tickets/month with current human costs of $25,000:
- Per-seat: 2 agents × $5,000/month = $10,000/month ($1 blended cost per ticket attempt).
- Per-conversation: 10,000 conversations × $0.40/conversation = $4,000/month.
- Per-resolution: 10,000 tickets × 92% resolution rate = 9,200 resolved × $0.99 = $9,108/month + overhead for escalation management.
- Outcome-based: 9,200 resolved × $1.20 (assuming 5% outcome failure) = $11,040/month, but vendor assumes risk of poor outcomes.
The cheapest look (per-conversation at $4,000) is false savings if it's hiding retries and multi-turn conversations. The per-resolution model looks expensive until you factor in that you're paying only for actual wins. The outcome-based model is hardest to forecast but protects you from paying for technically "resolved" tickets that create downstream costs.
Hidden Costs in Each Model
Every pricing model obscures something. Per-seat hides utilization: are your agents busy or idle? Per-conversation hides multi-turn depth and retry loops. Per-resolution hides the definition of "resolution" and the cost of edge cases. Outcome-based hides the vendor's margin pressure, which can lead to aggressive shortcuts (trading speed for accuracy).
The strongest vendors are transparent about what their pricing model doesn't include. Intercom Fin publishes that per-resolution pricing covers API cost and compute but not tool integrations (Stripe calls, Twilio SMS, etc.), which are billed separately. Sierra notes that their per-resolution fee assumes the agent is calling a defined set of backend systems; custom integrations add cost.
When evaluating agents, ask: (1) What counts as a billable unit? (2) What's excluded and billed separately? (3) What does the vendor's cost structure look like—are they incentivized to help you or to game the metric?
Pricing model alignment with your economics determines whether the agent fits your business. For high-volume, low-complexity support (customer account lookups, standard refunds), per-conversation or per-resolution scales well. For low-volume, high-stakes work (loan origination, insurance claims), outcome-based or per-resolution with deep integrations makes sense. For internal tools or specialized workflows, per-seat may still be right if you can guarantee high utilization.
For deeper analysis of total cost, including the hidden infrastructure costs underneath any pricing model, see the AI Cost Iceberg and Total Cost of Ownership.
The CFO's job is to see beyond the headline rate—$0.99 per ticket, $5,000 per seat, $0.40 per conversation—to the true economic impact of the model underneath. If you're building a business case for an AI agent and considering multiple vendors, run the numbers using each vendor's actual resolution rate, escalation rate, and integration cost. The pricing model that looks cheapest on a napkin often hides the most.
If you're building the case for work-item-level AI cost attribution within your organization, the CFO Field Guide to AI Costs walks through how to model and forecast agent spend under each pricing regime.
Go deeper with the field guide.
A step-by-step PDF for implementing AI cost attribution.
Was this article helpful?