The Meter Is Not the Value
AI SaaS is the subject of this series: a provider sells access to an AI model or agent, and a customer puts that capability to work inside an operating process. The question is not simply whether the customer should pay by seat or by token. It is what the price is meant to represent, which uncertainty the contract exposes, and what happens when the AI succeeds, fails, or hands work back to a person. The reader’s practical task is to judge a pricing design against the value and risk it creates in the customer’s full workflow.
That sounds like a technical distinction, but it is an economic one. A seat measures who is entitled to use a service. A token count measures one kind of computational consumption. An invocation records an attempt. An outcome describes something that happened to the customer’s work. These quantities can move together, but they do not have to. A busy team may use few tokens and create considerable value; a long exchange may consume many tokens and still leave the customer with an unresolved problem.
The central argument is therefore deliberately narrower than “subscriptions are obsolete” or “outcome pricing is always better.” Seats and tokens can be useful operating meters. They become inadequate when they are treated as the whole explanation of value. Good AI SaaS pricing must also account for task difficulty, probability of success, human fallback capacity, deployment and supervision cost, and the consequences of failure. The works considered here provide two complementary ways to see that problem: contract theory asks how a provider should charge when buyer types and success are partly hidden, while workflow economics asks what an AI agent contributes once it is embedded in a human–AI system.
AI SaaS Is a Workflow Relationship
An AI SaaS transaction is often presented as if it ended at the API boundary: the customer sends a request, the system returns an answer, and the invoice records usage. In practice, the returned answer is usually an intermediate object. It may be copied into a customer-service queue, checked by an analyst, incorporated into a forecast, used to draft a document, or passed to another system. If the answer is incomplete or wrong, someone may need to correct it, investigate it, explain it to a client, or absorb the consequences of acting on it.
That is why the provider–customer relationship contains more than a price and a model. It contains an AI agent or service, a task to be performed, people who supervise or receive the result, and a downstream process that turns the result into something valuable. In the customer-service setting described in Pricing AI as a Service, an AI service handles incoming requests while unresolved requests are escalated to human agents. The economic question is not merely how many requests the AI touched. It is whether the arrangement improves the service system after the human queue is included.
The same point appears in Agentomics, which treats AI agents as productive resources rather than as isolated pieces of software. An agent can generate output, consume resources, improve speed, introduce supervision requirements, and create reliability risk. Its economic contribution depends on the work around it. A capable detection agent may be valuable when analysts can process its alerts, but much less valuable if it overwhelms the people responsible for triage. A less impressive agent may be worthwhile when it handles repetitive work reliably and complements scarce human judgment.
This separates technical capability from economic value. A benchmark can tell us something about what an agent does under a defined test. It does not by itself tell us whether a customer’s workflow becomes more productive after integration, monitoring, correction, and escalation. The relevant comparison is not “model score versus model score.” It is the customer’s situation before and after deployment, including the costs and losses that the AI changes.
A useful first approximation is simple: economic contribution is the value created, less the cost of deployment, less the expected cost of failure. The formula is not a complete accounting system, but it prevents a common category error. Token consumption belongs somewhere in the cost side. It is not automatically the value side, and it does not capture every cost on either side.
What Seats and Tokens Can—and Cannot—Tell You
A seat-based plan is primarily an access instrument. It gives a defined group of users permission to use the service for a period. That predictability can be valuable: the customer can budget, the provider can forecast recurring revenue, and neither party must negotiate the price of every interaction. But a seat count says little about the work those users perform, the intensity of their use, or the consequences of an unsuccessful result. Two customers with the same number of seats may place very different demands on the service and receive very different economic benefits.
A token meter is closer to a usage instrument. Tokens are a useful way to track a variable computational input, especially when provider costs rise with processing. Yet resource consumption and customer value are not interchangeable. A request can be long because the problem is poorly structured, because the system must retry, or because the customer supplies necessary context. None of those facts establishes that the resulting work is valuable. Conversely, a short interaction can trigger a high-value decision or prevent an expensive error. A token price may be economically sensible while still being an incomplete measure of the service’s contribution.
An invocation fee sits between access and outcome. It charges for an attempt, whether or not the attempt produces the desired result. The SSRN work calls this conversation-based pricing, or CBP, and defines it as a fixed fee per invocation. An outcome-based contract, by contrast, charges only when the service succeeds. That design makes the provider’s revenue more visibly dependent on realized performance, but it also asks a harder question: who decides whether success occurred, and how should the price reflect the probability that success will occur for different customers and tasks?
The distinction can be seen without treating any meter as morally superior:
The diagram’s final node is the important one. Choosing a meter also chooses how the parties divide uncertainty. With an access or usage charge, the customer generally pays even when a particular attempt does not resolve the task, although the contract may provide other protections. With a success-contingent charge, the provider accepts more exposure to failure and to disputes over whether the outcome qualifies. Neither arrangement eliminates risk; each places it in a different part of the relationship.
The formal comparison in Pricing AI as a Service makes the issue sharper. Buyers may differ privately in how much they value the service and how difficult their tasks are. Task difficulty affects the AI’s probability of success. A provider that sees only a request and a payment cannot automatically tell whether a low success rate reflects a weak service, a difficult customer segment, or both. A contract is consequently not just a billing cadence. It is a mechanism for dealing with incomplete information.
“Alone” Is the Important Word
The title’s warning is contained in one word: alone. Seats and tokens are not useless because they fail to describe every consequence of a service. They are incomplete when a provider or customer uses them as a substitute for asking four further questions.
First, what counts as success? If the customer’s real goal is a resolved case, a correct investigation, or a useful decision, an invocation or token count may stop too early. The service may return text while leaving the customer with verification and repair work. Outcome pricing can make the intended result more visible, but only if the result is observable and difficult to game.
Second, what happens to unresolved work? The human fallback is part of the product’s economics. If the AI sends a manageable number of difficult cases to a capable team, it may improve the overall system. If it sends more cases than people can absorb, apparent automation can become congestion. The customer’s service rate and escalation process can change whether a contract is attractive.
Third, what costs persist after purchase? Integration, data preparation, monitoring, governance, security review, supervision, correction, and re-execution can remain important after the model is connected. A token bill may be accurate as far as it goes while still omitting the work required to make the service dependable.
Fourth, who bears the consequences when the workflow fails? A low-probability failure can matter greatly in healthcare, finance, cybersecurity, or other high-consequence settings. Pricing, service credits, insurance, audit, and responsibility are related design questions, even though they are not the same question. A contribution benchmark can help organize them; it cannot replace an incident investigation or a legal determination.
This gives the series its governing perspective. The right pricing question is not “Which meter is modern?” It is “Which observable charge, combined with which evidence about value and risk, gives both parties a defensible economic relationship?” The answer may be a subscription, usage pricing, an invocation fee, an outcome component, or a staged hybrid. It depends on what can be measured, how success relates to task difficulty, how the human fallback behaves, and how much failure costs.
That makes the next comparison concrete. When an AI SaaS provider charges for every invocation rather than only for a success, the change is not merely a new line on the invoice. It changes the screening problem, the allocation of performance risk, and the provider’s exposure to difficult tasks. Understanding that trade-off is the first step toward deciding when an outcome is a better pricing anchor—and when it is not.