Price per outcome, set the price on what the outcome is worth to the customer, and treat compute as your cost. That is the whole answer for pricing software when the customer is an AI agent. Not per seat, because an agent does not log in. Not per API call, because that makes you a commodity data vendor. Not marked-up tokens, because you would be pricing your cost instead of their value, and your cost is falling fast.
The rest of this post is the why, the three answers most companies reach for first, and a practical test for which outcomes you can actually charge for.
The unit problem
Every SaaS price is a count of something. For twenty years the something was a human with a login, and the human was a decent proxy for value.
An agent breaks the proxy. One agent can do the work of many people, so the seat count falls while the value delivered goes up. Intercom's head of pricing, on why Fin is not sold per seat: "If a company has 1,000 customer service employees and Fin works as well as we know it does, over time, those 1,000 seats might become only 200." a16z made the same point with Zendesk's $115-per-agent seat: when AI resolves the tickets, the natural metric becomes successful outcomes, not headcount.
And the agent calling your product may not be one you sold. Once a customer's own agent can reach your API, the "user" is a script running in someone else's account. There is no seat to count.
The question is not "seats or usage." It is "what is the unit."
Three bad answers
Most companies reach for one of these first. Each is understandable. Each fails for a specific reason.
1. Charge per API call, like a data vendor
The obvious move: meter the calls, publish a rate card. Easy to bill, feels fair.
The problem is that transport is going to zero. Cloudflare published a pattern that puts roughly 2,500 endpoints behind two tools in about 1,000 tokens of tool definition, and gave it away as something any vendor with an OpenAPI spec can copy. When reaching your primitives is free and easy, a per-call price is a price on a commodity. It gets compared, and it gets shopped.
Per-call pricing also pays you for the agent's inefficiency, not the customer's result. An agent that takes twelve calls to do a one-call job pays you twelve times. Customers notice. As pricing strategist Steven Forth wrote in his catalog of agent pricing failure patterns: "If you price on tokens, compute, or API calls, customers will optimize against you."
Per-call works for data vendors, where the record is the product. If it is not yours, do not price like it is.
2. Mark up tokens
The second move: pass through model cost with a margin. Credits, metered by whatever the model consumed.
This is pricing your cost, and your cost is collapsing. a16z measured that for an LLM of equivalent performance, the cost is decreasing by 10x every year. A margin on a number that falls 10x a year is a shrinking business unless you keep raising the multiple, and customers see the multiple.
It also puts the bill on something the customer cannot predict. Microsoft meters Copilot Cowork in Copilot Credits, and the admin tooling around it is mostly spending policies, limits, and alerts. That is the tell. When the price is on consumption the customer did not choose, you end up selling controls for a meter they never asked for.
Intercom's pricing lead made a prediction worth taking seriously: "The companies still charging purely by token in two years will be the outliers."
3. Give agents free access and hope
The third move is the quiet one. Open the API, ship an MCP server, let agents in, figure out money later.
Free access is table stakes, not a strategy. Cloudflare gives away code mode. The cost of letting an agent reach your product is heading to zero whether you charge for it or not.
What free access does is turn your product into a primitive in someone else's outcome. The buyer's agent composes your endpoints with three other vendors' and delivers a result. The buyer pays for the result, and the result is not yours. The buyer's agent becomes the aggregator, and you become one of its suppliers.
Hope is not a pricing model.
The good answer: price the outcome, set on value
Charge for the thing the customer wanted. Set the price on what it is worth to them. Pay for compute yourself, the way you already pay for servers.
The public examples so far are in support, where the outcome is clean. Intercom charges $0.99 per resolution, defined as "No further help is requested after Fin's last answer," and a very different $9.99 per qualification because a qualified lead is worth more than a closed ticket. Zendesk charges $1.50 per automated resolution, counted after a 72-hour quiet period. Sierra has argued since 2024 that the unit should be a resolved support conversation, a saved cancellation, an upsell, a cross-sell, with blended pricing where an interaction is just routing.
Salesforce sits on the other side of the line. Agentforce is $2 per conversation or 20 Flex Credits ($0.10) per action. Both are activity. Neither asks whether the case got resolved. That is the difference between charging for what the agent did and what the customer got.
Note what none of these vendors do: itemize the model bill. Twilio is the older version of the same idea. Its US SMS price is $0.0083 per segment. Carrier surcharges appear as pass-through line items, but the unit you buy is a message, and Twilio's margin is never something you see. The buyer reasons in messages. Your buyer should reason in outcomes.
Deloitte's accounting guidance is a sanity check: is your promise a stand-ready obligation to provide access, or an obligation to deliver a specified quantity of successful outcomes? If finance cannot say, customers cannot either.
Why would anyone pay for an outcome their agent could compose?
This is the real objection. If the buyer's agent has your public API and your docs, why pay you for a result it could assemble itself?
It would not, unless one of four ingredients is present.
Privileged data. The outcome needs something the public API never exposes: cross-tenant benchmarks, internal risk signals. The buyer's agent cannot compose what it cannot reach.
Write authority with accountability. The outcome changes state in your system. No sane vendor hands an arbitrary agent headless control over deletes, refunds, or bulk updates. Outcomes with side effects only exist as vendor-sanctioned jobs with guardrails and an audit trail. That job is yours to sell.
Residency. The buyer's agent is not running at 3am. Scheduled and event-triggered work needs a runtime that lives next to the product and is awake when the event fires.
Amortized reliability. You tested it once and run it thousands of times on the cheapest model that passes. The buyer's agent would figure it out fresh, on a frontier model, with no run log. This is real today. It also erodes every time models improve, so it must never be the only reason someone pays you.
Here is the practical test. For each outcome you might sell, ask: could a competent agent with the public API and the docs produce this result on its own? If yes, do not price it. Ship it as a primitive and move on. If no, name which of the four ingredients blocks it. That ingredient is what you are actually selling, and it is how you defend the price.
Three jobs and how their prices take shape
The numbers below are illustrative, not from any customer or market study. The shapes are the point.
The unit worth pricing is rarely a single run. It is a job your product owns for a customer and keeps working, with a state anyone can check. We made that case in Outcome as a Service: A Service Is a Job, Not a Task. Here is how it plays out on price.
Keep every location compliant. Subscription per location. "Every location stays current on the training it is required to have." It needs privileged data (who is due, across the whole account) and residency: it watches for slips, enrolls the people who fell behind, and loops in the manager. The value is the standing state, 11 of 12 locations compliant, not the count of reminders sent. Flat monthly price per location, something like $29.
Get every new hire through onboarding. Priced per hire. "Each new hire is set up, enrolled, and through week one." It needs write authority: accounts get created, courses assigned, permissions set. Each hire has a clear finish line, so a per-hire price fits, something like $15 per hire who completes onboarding, and nothing for one who never starts.
Renew every certificate before it lapses. Subscription with a ceiling. "No certificate in the account expires unnoticed." It needs residency and amortized reliability: the same checks, every day, on the cheapest model that passes. Price as a monthly subscription that covers a number of certificates, with a per-certificate price past that, so a large account pays more than a small one. Something like $99 a month for 100 certificates, $1 for each one past that.
Reports, reminders, and escalations show up inside all three. None of them is what the customer pays for. They are what the job does to hold its state.
No seat in any of these. No token either. You carry the compute, and the customer can point at the thing they paid for.
The part that goes wrong
Outcome pricing has one hard problem, and it is not billing. It is agreeing on what "done" means.
Intercom bills a resolution when no further help is requested. Zendesk waits 72 hours of quiet. Both are proxies for "the customer was helped," and a customer who gave up looks identical to one who was satisfied. When a YC billing startup launched outcome-based pricing on Hacker News, gaming came up fast: one commenter asked whether a bot that replies "Ticket closed" to every query would make bank.
The way through is to sell outcomes your own system can verify. A location is compliant when your records show every required course complete. A new hire is onboarded when the account exists and week one is done. A certificate is renewed when the new expiry date is in your database. Those are facts in your logs, not claims in someone else's CRM. If you cannot observe it, you picked the wrong outcome.
Two more cautions. Keep a platform fee if you need a floor; Sierra's own post concedes pure outcome pricing does not fit every interaction. And decide up front what a failed run costs. The customer should never pay for an outcome that did not happen, and you should never eat unlimited retries. Put both on the pricing page.
Where Aimdoc fits
We built the delivery side of this. Aimdoc connects securely to a software product and to the company's own systems, then delivers the work each customer needs: metered, monitored, and cost controlled. A service is a job the AI owns for each customer and keeps working with your tools, like the three above. Put a price on a job and customers buy it through your own Stripe account, usually as a subscription. What you charge is yours to set; what you pay Aimdoc is prepaid credits for the AI's work. You can start with 10,000 free credits, no credit card. For the delivery half of outcome pricing in more depth, read Outcome-Based Pricing: Delivering the Outcome Is the Hard Half.
The short version
Seats count humans. Agents are not humans. Calls and tokens count your cost, and your cost is falling. Free access makes you a primitive in someone else's product.
So count outcomes. Set the price on value. Carry the compute. Sell only the outcomes a competent agent could not assemble from your public API, because privileged data, write authority, residency, or proven reliability blocks it.
Primitives are not products. Someone has to own the job, guarantee it, and sell it. If it is not you, it will be the buyer's agent, and the buyer will pay someone else.
Read how we handle the tool-count side of this in Too Many MCP Tools Makes Your Agent Worse, define your first service, or book a demo.