Field notes · AI business · Oct 2026 · 13 min read

When AI does the work, who answers for it? Why SaaS is moving from seats to outcomes, and why proof becomes the product

Two ways to pay for the same help. Under the old deal an AI helper cuts the seats and the vendor loses income. Under the new deal the customer pays per collected invoice, and the result must be proved.

In one sentence: Software used to charge for each person who logged in. When an AI does the work, fewer people log in, so the price has to follow the work done instead, and the vendor must then prove the work was done.

Start at the end: the problem, told backwards

Most stories start at the beginning. This one starts at the bad ending, then rewinds to find the cause. Read the poster from the top down. Each step asks "why?".

A poster that tells the Billbook story backwards. Now: the customer asks whether the AI really collected 200 invoices, and Billbook has no records, so it refunds the money. Why? Because Billbook now charges for each result. Why? Because the AI helper cut the seats from ten to three and income fell from two hundred to sixty dollars. Why? Because the AI helper does the chasing by itself. Start: one seat, one person, one price, which worked for twenty years. Seats count people, AI counts work, so the price follows the results and the results need proof.

The rest of this article tells the same story forwards, then shows what to do about it.

Think of a school bus pass

A bus pass costs the same whether you ride once or fifty times. That is simple for everyone. Now imagine a new kind of bus that takes you to school without you standing at the stop. Would you still pay for a pass? You would rather pay for the trips that really happened.

Business software is going through the same change. For twenty years, most of it was sold by the seat: one price for each person who logs in. The AI is now doing some of the work those people did. So the number of seats goes down, and the old price stops matching the value.

What the old deal looked like

Seat pricing worked because it was a good guess. More people using the tool usually meant more value. A bigger team paid more. A company knew its bill in advance, and the vendor knew its income in advance.

It was also cheap to run. Once the software was built, one more customer cost almost nothing, so most of the price was profit.

What changed

An AI agent is a program that can finish a job by itself, such as chasing unpaid invoices or answering a customer. One agent can do the work of several people. That breaks two things at once:

The guess breaks. Fewer people log in, but the value is as high as before, or higher.
The cheap-to-run part breaks. Every job the AI does uses tokens (the small pieces of text it reads and writes), and tokens cost money each time. One more customer is no longer almost free.

Two ways to pay for the same help. Old deal: ten seats at twenty dollars is two hundred, and after an AI helper only three seats are needed, so the vendor loses one hundred forty dollars. New deal: two hundred collected invoices at one dollar fifty is three hundred dollars. A result is only worth billing if you can prove it happened.

A story: Billbook

Billbook is a made-up invoicing app. All its numbers here are invented to show the idea.

Year 1. Ten people at a customer log in to Billbook. Each seat costs $20 a month, so Billbook earns $200 a month from that customer.

Year 2. Billbook adds an AI helper that chases late invoices by itself. Now the customer needs only three people to log in. The bill drops to $60. The customer is happier. The helper is working well. And Billbook has just cut its own income by seventy percent.

Year 3. Billbook changes the deal: $1.50 for every overdue invoice that really gets paid. This month the helper collects 200 invoices, so the customer pays $300. Billbook now earns more, and the customer pays only for results.

That sounds like a happy ending. It is not the end of the story.

The cost problem. Each time the helper tries to collect an invoice, it uses tokens. Tokens cost money. The price of tokens has fallen a lot, but the new, smarter helper thinks for longer, checks its work and tries again. It uses many more tokens each time.

A table for one collected invoice. The price per million tokens falls from ten dollars to one dollar. Tokens used per attempt rise from twenty thousand to four hundred thousand. Cost of one attempt rises from twenty cents to forty cents. Success rate improves from eighty to ninety percent. Cost of one success rises from twenty-five cents to forty-four cents.

Read the table from top to bottom. The price per token fell by ninety percent. But the cost of one finished job went up by about seventy-eight percent, because each try uses twenty times more tokens. Nothing here is a mistake. It is just arithmetic.

The proof problem. At the end of the month the customer looks at the bill and asks: "Did the helper really collect these 200? Or did the customers pay on their own?" If Billbook cannot show clear records, it must give the money back, or lose the customer.

The build-it-ourselves problem. The customer also asks: "AI tools make it cheap to write software. Why not build our own invoice chaser?" Billbook's honest answer is not "we have an AI". Anyone has an AI. The honest answer is "we can show it works, we log everything, and we answer when it is wrong."

Cost per successful job: the number that matters

Most teams watch the price of a call to the AI. That is the wrong number. A call that fails still costs money, and a retry costs money again. The number to watch is:

Cost of one success = cost of one attempt ÷ how often an attempt works.

In the Billbook table, one attempt costs 40 cents and works 9 times out of 10, so one success costs about 44 cents. Billbook charges $1.50, so it keeps about $1.06. If the helper started failing half the time, one success would cost 80 cents, and the profit would shrink fast.

This is why a single number like "gross margin" is no longer enough. The margin now moves with every change to the AI model, every retry rule, and every new kind of job. See Test the cheap things first for one way to keep your own testing bill under control.

How companies charge now

Way to charge	You pay for	Good	Risk
Per seat	Each person who logs in	Easy to predict	Falls as AI does the work
Per use	Each call, action or token	Fair for heavy and light users	The bill is hard to predict
Per output	Each thing produced (a report, an email)	Clear to count	The thing may be useless
Per outcome	Each result that counts (a paid invoice, a solved case)	Matches the value	Needs proof of the result

Most companies today use a mix: a smaller seat fee plus credits for the AI work. Very few charge only for outcomes, because proving an outcome is hard. A real example: Intercom charges $0.99 each time its AI agent solves a customer's problem.

Who gets the saving?

Here is a quiet problem. If the AI does the job for 44 cents and the vendor charges $1.50, who gets the saving? The customer once paid for ten people. Now they pay for results. The vendor may keep most of the gain.

There is a second problem. If the vendor is paid for every "resolved" case, it may be tempted to count a case as resolved too easily. A fair deal needs a clear, shared definition of a good result, and a way for either side to check it.

Will AI kill SaaS? Will it kill jobs?

You will read that "SaaS is dead" and that AI will end jobs. Here is the author's view, in plain words. It is a view, not a proven fact.

The author's view. AI will change SaaS and change work. It will not end either one by itself. What breaks is the old price tag, and the old way of splitting up the work.

Three old ideas are breaking:

"More people means more value." An AI helper does the work, so fewer people log in.
"One more customer costs almost nothing." Every job the AI does costs tokens, so each customer now has a real cost.
"A nicer screen is enough." AI can now build screens cheaply, so a copycat is easy to make.

What is still hard to copy? Five things:

Your customers' trusted data.
The place where the work is kept and checked.
Rules and approvals.
A record of what happened.
A person who answers when it goes wrong.

Look at the list. Almost all of it is trust. That is why proof becomes the product.

And what about people's jobs?

Fewer people log in. That is not the same as fewer people being needed. Someone still has to:

decide what a good result is,
check that the result is real,
handle the cases the AI gets wrong,
and answer to the customer when something goes wrong.

That work does not disappear. It moves, from doing the task to owning the result. Some roles will shrink and some will change a lot. A leader owes their team an honest talk about that, not a slogan. Nobody can prove how many jobs will change, so be careful with anyone who gives you a number.

What the new model looks like, and how to line up with it

The new model is not "charge only for outcomes". It is closer to a three-part deal that both sides can check:

A base fee for the system, the data and the support. This keeps income steady.
A price for results when a result is clear and countable, with a cap so the customer's bill cannot explode.
A proof pack: the records that show what the AI did, what it was allowed to do, who approved it, and what it cost.

Here are seven moves for a team that sells software today:

Count your cost per success, not your cost per call. Track it every week.
Define an outcome in one sentence that a customer and a vendor can both check. Put the sentence in the contract.
Earn freedom in steps. Let the AI advise first, then act with approval, then act alone inside limits. Move up only when the evidence is there. Autonomy is earned explains the five levels.
Keep a test that cannot be fooled. "No failures" in a small test is not proof. Zero failures is not proof shows why.
Log every action with who or what did it, what it was allowed to do, and what it cost, so a dispute can be settled with facts.
Share the saving in a way a customer can see: a lower price per result over time, or a bonus for better quality.
Keep the system of record. Be the place where the work is stored, checked and approved. That is much harder to rebuild than a screen. If customers can build a tool quickly with AI (see Vibe coding in 2026), your edge is proof and accountability, not the screen.

Five questions before you price by outcome

Can we say in one sentence what counts as a result?
Can the customer check it without trusting us?
Do we know our cost per success, and how it moves if prices or models change?
What happens when the AI is wrong: who pays, and how fast do we notice?
Do we have enough evidence to let the AI act alone, or should a person still approve?

The limits of this advice

The Billbook numbers are invented. Real prices, costs and success rates will differ.
Outcome pricing does not suit every product. Where results are vague or slow to show, seats or usage may still be better.
Forecasts about the future of pricing are guesses. Some come from analysts, some from surveys of a few companies. Treat them as direction, not as dates.
That AI will not end SaaS or jobs by itself is the author's judgement, not a forecast. Some products and some roles will shrink.
A vendor with a great proof pack can still lose to a cheaper rival. Proof helps with trust, not with every sale.
This article covers software companies. It does not give legal or tax advice, and contract wording needs a lawyer.

Words explained

SaaS: software you rent over the internet instead of installing, such as an invoicing app.
Seat: one person's login to a paid tool.
AI agent: a program that can do a job by itself, in several steps, not just answer a question.
Token: a small piece of text an AI reads or writes. AI companies charge by the token.
Outcome: a result you can count and check, such as an invoice that was paid.
Gross margin: what is left of each sale after the cost of delivering it.
System of record: the main place where a company's important facts are kept and trusted.
Release gate: a final test an AI must pass before it is given more freedom.

For engineers

This section has the sources and the exact reasoning. Everything above is the simple version of it.

Cost per successful task. cost_per_success = (tokens_per_attempt × price_per_token × attempts) ÷ successes. Track it per task type, not as one blended number. Include retries, tool calls, judge calls and any human review time. Billbook's figures are illustrative: $10 to $1 per million tokens, 20,000 to 400,000 tokens per attempt, 80% to 90% success.
Unit price down, spend up. Fortune reported on 17 June 2026 that a Silicon Data index shows the price of a token down more than 90% since 2023 while spending on large language models has doubled since late 2025. Torsten Slok, chief economist at Apollo, called it the Jevons paradox in action: as tokens get cheaper, companies run more agents. Source: Fortune, 17 June 2026. The index and the quote are secondary reporting; read the index before quoting further numbers.
Forecast on pricing. Deloitte's TMT Predictions 2026 (18 November 2025) quotes Gartner: "By 2030, at least 40% of enterprise SaaS spend will shift toward usage-, agent-, or outcome-based pricing." This is a forecast, not a measurement. Deloitte also notes that proving an AI agent created value or a business outcome could be challenging, that revenue for vendors and costs for customers could become less predictable, and that agentic systems still need to prove they can produce consistent and reliable value. Source: Deloitte Insights.
Real outcome price. Intercom lists $0.99 per Fin outcome, with the three conditions above and one billed outcome per conversation. Prices change, so check the page for current terms; this was read on 26 October 2026: Intercom pricing. Naming a product here is an example, not a recommendation.
Output vs outcome. Many offers called "outcome-based" count outputs (a message sent, a document made). A true outcome needs an external check (money received, ticket not reopened in N days). Define the check, the time window, and who may dispute.
Proof pack. Per action: input reference, model and version, policy applied, autonomy level at the time, approver if any, tool calls, cost in tokens and money, and the outcome check. Keep it append-only. This is the same evidence the release gate in Autonomy is earned needs.
Price floor and cap. Floor: expected cost per success at the 90th percentile of retries, plus margin. Cap: a monthly maximum per customer, so a spike in volume or retries cannot become an unbounded bill for either side.
Release gate for billing. Before moving a task from "with approval" to "alone and billed per outcome", require a held-out test set, critical-case blockers, and a confidence bound on the success rate, not just "no failures". See Zero failures is not proof and Chapter 12.
Not covered, and why. EU AI Act timing is still moving: a provisional political agreement of May 2026 would delay some high-risk obligations, but final adoption was not confirmed when this was written, so no dates are given here. Seat-share statistics and CEO survey figures seen in secondary blogs were not traced to a primary source and are left out.
Where it fits. Evaluation engineering and the release gate (Chapter 12), the two dashboards for quality and cost (Chapter 22). Related: AI caching, explained simply for one way to lower the cost per success.

In the book

Evaluation Engineering Two Dashboards, Not One

General engineering lessons from the author's own experience, with illustrative examples. They describe no particular company, product or customer and are the author's personal views. Disclaimers