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 resolutions, 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. Okibi, which relaunched this week, generates a CLI from your product spec on a free tier. 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. Merchants needed Shopify more, not less, once customers shopped through aggregators. The aggregator this time is the buyer's agent.
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 outcomes and how their prices take shape
The numbers below are illustrative, not from any customer or market study. The shapes are the point.
An audit. One-time. "Review this account's configuration against what we know works and return what is wrong, ranked." It needs privileged data (what works across tenants) and it is done when the ranked list exists. One-time price, something like $150 per audit, if a good implementation engineer would bill a few hours for the same work. Sold from inside the product, with a run log the customer can read.
A monitor. Subscription. "Watch for X and act within the rules when it happens." A reorder threshold, a failed sync, an account going quiet. It needs residency and write authority: it fires at 3am and it changes state. Flat monthly price, because the value is the standing guarantee, not the count of events. Something like $49 a month per monitored scope, with the actions it may take listed on the tin.
A recurring report. Included runs plus overage. "Every Monday, the forecast for the next two weeks, delivered to Slack." It needs residency and amortized reliability. Price as a bundle: a number of runs included in the plan, then a per-run price past that, so a daily runner pays more than a weekly one. Something like 4 runs a month included, $12 per extra run.
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. We wrote about what that does to a bill. When a YC billing startup pitched outcome-based pricing on Hacker News, the top objection was gaming: one commenter described a bot that replies "Ticket closed" and makes bank. Others asked how you verify work at all when the count is self-reported.
The way through is to sell outcomes your own system can verify. An audit is done when the report exists. A monitor acted when the write landed. A report ran when it was delivered. 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 vendor side of this. Aimdoc runs one customer agent for a software product, on the website, inside the app, over email, and through a public Gateway for other agents. It connects to the product's MCP server; every call runs as the signed-in customer with their permissions. A service is a named outcome on top: inputs, allowed tools, limits, identity, entitlements, an optional price charged through the vendor's own Stripe account, delivery to app, email, Slack, or webhook, scheduled or event-triggered. The three examples above are the shapes services take. Free tier: 10,000 credits, no credit card.
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 design, guarantee, and sell the outcome. 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.