--- title: "AI Agent Pricing Models, Compared by Who Pays When It Fails" publishedAt: "2026-10-14" summary: "AI agent pricing models differ less in price than in risk. Compare them by who pays when the agent fails, wastes work, or only looks done." author: "Ben Skoog" authorImage: "/ben_skoog.jpeg" --- There are five common AI agent pricing models: per seat, per unit of usage, prepaid credits, per conversation, and per outcome. Most guides compare them on predictability and value alignment. A more useful way to compare them is to ask who pays when the agent gets it wrong, because every one of these models is really a decision about where that cost lands. An agent can get it wrong in three different ways. It can fail outright and finish nothing. It can waste effort, taking twelve steps for a one-step job. Or it can look done without being done, closing a conversation the customer simply gave up on. Each pricing model sends each of those failures to a different party, and the published price lists show exactly where. The ranking guides cover the first failure well and mostly skip the other two. The third one matters most, because it is where per-outcome pricing, sold as the model with no risk for the buyer, quietly moves the argument somewhere else: from the price to the definition of done. ## The five models, in one table | Model | What the buyer pays for | Example from a published price list | |---|---|---| | Per seat | People with access | Agentforce User License, $5 per user per month, which "requires Flex Credits" ([Salesforce](https://www.salesforce.com/agentforce/pricing/)) | | Per unit of usage | Each action or answer | Agentforce Flex Credits, $500 per 100,000 credits, with an action costing 20 credits, about $0.10 each ([Salesforce](https://www.salesforce.com/agentforce/pricing/)) | | Prepaid credits | A pool of capacity spent on work | Copilot Credits: 2 per generative answer, 5 per agent action ([Microsoft](https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-messages-management)) | | Per conversation | Each interaction, finished or not | Agentforce Conversations, $2 per conversation ([Salesforce](https://www.salesforce.com/agentforce/pricing/)) | | Per outcome | A counted result | Fin, "$0.99 per outcome" ([Intercom](https://www.intercom.com/pricing)) | Two things stand out. Salesforce sells three of the five models on the same page, which tells you none of them is a settled answer. And the line between usage and credits is thin: credits are usage, prepaid and pooled. The difference is who controls the ceiling, which turns out to matter. ## Failure one: the agent finishes nothing This is the failure everyone discusses, and the models sort cleanly. - **Per seat.** The buyer pays whether or not anything gets done. The vendor is paid for access, so a failed task costs the vendor nothing directly. - **Usage and credits.** The buyer pays for the attempts. A run that calls five tools and fails still used five tools. - **Per conversation.** The buyer pays for the conversation, resolved or not. - **Per outcome.** The vendor eats the failure. [Sierra says](https://sierra.ai/blog/outcome-based-pricing-for-ai-agents) "If the conversation is unresolved, in most cases, there's no charge," and the same for escalations. Pricing advisors are blunt about the usage side. Steven Forth, in his catalog of [failure patterns in AI agent pricing](https://pricinginnovation.substack.com/p/failure-patterns-in-ai-agent-pricing), writes that "Charging for failed work is equivalent to charging for harm and will trigger immediate trust breakdown." [Schematic's guide](https://schematichq.com/blog/ai-agent-pricing-models) recommends a practical fix for credit systems: place a hold before a task and deduct only after it completes, releasing the hold on failure. On this failure alone, per outcome wins for the buyer. That is why it gets the attention. ## Failure two: the agent wastes effort An agent that takes twelve calls to do a one-call job did finish. It just cost more than it should have. Who pays for the eleven extra calls? - **Per seat.** The vendor pays, in compute, out of a fixed fee. Nobody else notices. - **Usage.** The buyer pays, eleven times over. Forth's summary of this pattern is the most quoted line in the field: "If you price on tokens, compute, or API calls, customers will optimize against you." - **Credits.** The buyer pays, but only up to the pool. Microsoft's documentation shows what a cap looks like in practice: when a tenant reaches 125% of its prepaid capacity, "Custom agents are disabled," and admins can set monthly limits for individual agents before that point ([Microsoft](https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-messages-management)). Waste is bounded, though a hard cutoff is its own cost. - **Per conversation and per outcome.** The vendor pays. A long conversation and a short one cost the buyer the same. So outcome and conversation pricing move the waste to the vendor, and usage pricing moves it to the buyer. Credits split it: the buyer pays for waste, but the buyer sets the ceiling in advance and can see the meter. This failure is mostly invisible in the per-outcome model, and that is fine for the buyer. It is not fine for the vendor's margins. Forth notes that "AI compute costs can reach 70% of total delivery cost," which is why a vendor on outcome pricing has every reason to make its agent efficient, and a vendor on usage pricing has, at best, a weaker one. ## Failure three: the agent looks done without being done This is the failure the comparison guides skip, and it is where per-outcome pricing gets interesting. Under per-outcome pricing, the buyer pays only when an outcome is counted. So the whole risk question moves into one sentence: what counts? Read the published definitions and you see each vendor drawing that line differently. [Intercom's pricing page](https://www.intercom.com/pricing) says an outcome is counted when "A customer confirms their issue is resolved," when "A customer stops asking for help after Fin has replied," or when "Fin completes a workflow (Procedure), including handoffs." The second trigger is the one to read twice. A customer who stops replying because they gave up looks, from the outside, the same as a customer whose problem was solved. [Zendesk's definition](https://support.zendesk.com/hc/en-us/articles/9570369117338) goes further to separate those two cases. It sorts conversations into tiers. An "assisted escalation" and a "contained resolution," where the customer did not ask for more help but the conversation failed an LLM check, do not count against the allowance. Only a verified resolution does, after an LLM reviews the finished conversation. On email, "The conversation ends 72 hours after the first email in the conversation," so the verdict waits. Neither approach is wrong. They are different answers to the same hard question, and that is the point: per-outcome pricing does not remove the risk of a bad result. It turns that risk into a definition, written by the vendor, which the buyer has to read and agree with. [Sierra](https://sierra.ai/blog/outcome-based-pricing-for-ai-agents) makes the same promise from the other side: "We provide clear, agreed-upon criteria for each outcome upfront." Forth names the vendor-side version of this trap "Value Metric Overreach": "Do not claim full credit for outcomes influenced by humans, market conditions, or adjacent systems." A definition that is too generous to the vendor turns every renewal into a dispute. ## The three failures in one view | Model | Fails outright | Wastes effort | Looks done, isn't | |---|---|---|---| | Per seat | Buyer | Vendor | Buyer | | Usage | Buyer | Buyer | Buyer | | Credits | Buyer, within a cap | Buyer, within a cap | Buyer | | Per conversation | Buyer | Vendor | Buyer | | Per outcome | Vendor | Vendor | Depends on the definition | Read down the last column and the pattern is clear. Every model except per outcome leaves the "looks done" risk with the buyer, because none of them is paying for done in the first place. Per outcome is the only model that even tries to price it, and it can only be as good as its definition of done. ## Two questions people merge Most writing on agent pricing blurs two separate decisions. 1. **How a software company pays for the AI that does the work.** This is a cost of goods question. Usage, credits and outcome fees all show up here. 2. **How that software company charges its own customers for the work.** This is a product question. The answer can be completely different from the first. A vendor can pay for its AI in prepaid credits and still sell its customers a fixed monthly price for a job done. The vendor then carries the gap between the two, which is exactly what a service business does. We argued in [outcome-based pricing for software companies](/blog/outcome-based-pricing-for-software-companies) that the hard half of outcome pricing is delivery, not the price. The same logic holds here: the vendor that can define done inside its own product is the one that can safely take the "looks done" risk off its customers. And if your buyer is itself an AI agent, the pricing question changes again, which we covered in [how to price your software when the customer is an AI agent](/blog/how-to-price-your-software-when-the-customer-is-an-ai-agent). ## Which model fits - **Per seat** fits an assistant that helps a person do their own work. It fits badly once the agent does the work without the person. - **Usage** fits when the buyer is technical, wants fine control, and can see the meter. It punishes inefficiency, but the buyer pays for it. - **Credits** fit when work is varied and hard to define in advance. The buyer pays for effort, but sets the ceiling. - **Per conversation** fits high-volume, short interactions where nearly every conversation ends in the same kind of result. - **Per outcome** fits when done can be defined in data both sides trust. Support resolution is the clearest case, and even there the definitions differ. ## Where Aimdoc fits, and how we price Aimdoc bills software companies in prepaid credits. On our [pricing page](/pricing), credits are units of the AI's work: conversations, setting up new customers, and the ongoing work on every job the AI owns. Billing is prepaid and capped, the vendor chooses the budget, and usage is metered and monitored so there is no surprise bill. Aimdoc never charges per outcome or per resolution. Why credits, given everything above? Because the work our customers' AI does is not one kind of event. A job like "get every new hire through onboarding" is a state to hold over weeks, not a ticket to close, and a single per-outcome fee does not describe it well. Credits put the waste risk with the vendor, but inside a ceiling the vendor sets and a meter it can inspect. The outcome price belongs one level up. What a software company charges its own customers for a job is its own price, through its own Stripe account, usually a subscription for the job. That is where the "looks done" risk can be taken off the end customer, by the company that can actually see whether the job is done. See [selling services through your own Stripe](/services/sell) for how that works. ## FAQ ### What are the main AI agent pricing models? Per seat, per unit of usage, prepaid credits, per conversation, and per outcome. Many vendors combine them, for example a per-user license that also requires usage credits, as on [Salesforce's Agentforce pricing](https://www.salesforce.com/agentforce/pricing/). ### Is outcome-based pricing risk-free for the buyer? No. The buyer stops paying for failed attempts, but the risk of a result that only looks complete moves into the vendor's definition of an outcome. Read that definition before comparing prices. ### Why do some AI products use credits instead of outcomes? Credits suit work that varies in size and is hard to define as a single countable event. The buyer pays for effort but sets a ceiling in advance. --- Your customers want the job done, not a meter to watch. Aimdoc delivers the work through your product, prepaid and capped, and lets you [sell the job at your own price](/services/sell). [Start free](https://app.aimdoc.ai/signup) or book a demo.