ThoughtSpot launched AgentSpot on October 22 with a pricing line most vendors would never print: "Priced by Outcomes, Not Tokens." No charge for tokens. No charge for seats. You pay only when an agent delivers work: a conversation, a workflow run, or an app session. Building and testing is free.
This is AI agent outcome pricing, and it is spreading. The same day, Kochava shipped the other answer to the same anxiety: token budgets and model routing inside StationOne Enterprise. Admins set token or dollar budgets per user or team, and the platform routes each request to the cheapest model that can handle it. One vendor stopped metering the input. The other built a better meter.
Both moves answer the same problem. AI costs stopped being predictable, and unpredictable costs stall adoption. The industry has tried three price tags in about eighteen months. The newest one sounds like the vendor finally takes the risk. Look closely at what counts as done, and the risk went somewhere else.
The Billable Event Problem
Outcome-based pricing for AI agents means you pay when the vendor's system records a completed unit of work, not when you use a seat or burn a token. That is the whole model. Everything else is contract language.
And the contract language is where it gets interesting. Every outcome-priced deal has a billable event. For AgentSpot, it is a conversation, a workflow run, or an app session, per the company's October 22 announcement. Sounds concrete. It is not. A conversation that answered nothing still happened. A workflow run that produced garbage still ran. A session where the user gave up still counts as a session.
Three questions decide whether the pricing is fair.
Who defines done? If the vendor's counter increments when their system finishes a turn, then "done" means the machine stopped talking. That is not the same as the job getting done. Your definition and theirs can diverge on every single unit.
Who counts the units? The vendor's telemetry is the meter, and the invoice comes from the same company. You are trusting one party to be the cashier and the auditor.
What happens when done is wrong? If a completed conversation was useless, do you still pay? If yes, you bought a pricing model that charges for effort with better branding. If no, who decides, and how fast?
I have written about the measurement collapse in agentic AI. This is its commercial twin. When the vendor owns the definition, the meter, and the invoice, measurement stops being a shared discipline. It becomes a vendor feature.
Why the Vendor Wants This More Than You Do
Here is the part nobody says out loud. Outcome pricing is not vendors being generous. It is vendors escaping a problem that was killing their deals.
Token bills were scaring buyers. Every pricing page that said "pay per token" asked a CMO to sign a variable-rate check. Procurement teams hate variable rates. Finance teams hate surprises. Pilots stalled while everyone waited to "think about the cost model." Vendors watched token anxiety slow adoption and decided the meter was the problem.
Outcome pricing removes the scary meter and replaces it with a friendly one. A buyer who would never approve an uncapped token budget will approve "pay per completed conversation," because it sounds like paying for results. The buyer stops doing math. That is the point.
Kochava took the other road. Instead of hiding the meter, they built a better one: budgets per user and team, routing to the cheapest capable model, usage reported by business task, even the option to run compatible models locally so some work never touches the meter at all.
Two vendors, same diagnosis, opposite prescriptions. One says the answer is a better meter. The other says the answer is no meter. Both are selling the same thing underneath: budget predictability. Kochava sells it through control. ThoughtSpot sells it through simplicity. The price of the simple version is auditability. You cannot audit what you cannot define, and you did not write the definition.
Three Clauses Before You Sign
None of this makes outcome pricing a scam. It is a pricing model, and every pricing model favors whoever writes the terms. Write some of the terms yourself.
First, define done in your words. Do not accept the vendor's billable event as the contract's definition of completion. A completed conversation should mean the agent resolved the request to your standard, not that a session ended. Tie the billable event to your success criteria. If the vendor will not put your definition in writing, you learned something important.
Second, audit the count. Demand the event log behind every invoice: which units fired, when, and what each one contained. Reconcile it against your own telemetry. I have written about the invisible costs of agent failures. A billable unit that produced nothing is the same failure with a price tag. The audit does not have to be adversarial. It has to exist.
The vendor counts the units. Count them yourself too.

Third, cap it and keep a kill switch. Put a monthly ceiling on billable units. Keep a termination right that triggers when the definition of done drifts, because definitions drift. Every "completed" unit gets a little easier to complete over time. A cap turns that drift into a conversation instead of a surprise. Run all of this past your counsel. It is an operating checklist, not legal advice.
The Metric That Matters Now
The industry spent two years arguing about token costs. The next two will be about outcome definitions.
Watch for the signs. Vendors will quietly broaden what counts as a completed unit. Benchmark reports will move from cost per seat to cost per completed outcome, and vendors will sponsor the reports. Procurement teams will add "billable event definition" to vendor questionnaires, right next to the security review.
The buyers who wrote their own definition of done will be fine. Everyone else will discover the definition in a renewal meeting, a year after the meter started running.
The definition of done belongs in the contract, not in the vendor's docs.

The invoice got simpler. The question got harder. Every pricing model in software history favored whoever wrote the terms, and this one is no different. Ask who defines done now, or find out in a renewal meeting later.

