A site sits under its monthly minimum. The rated usage for the period comes in below the floor, so the invoice charges the floor — and a naive billing engine then debits the whole floor against the customer's annual cap, quietly handing back headroom the contract never granted. The rules are all individually correct. The invoice is wrong. That failure lives in the interaction between the rules, and it is where ML LABS spent the hard part of building the usage-based billing system behind the cloud ECG platform: per-unit rates by category, per-site minimums, annual caps, and category toggles that can be switched mid-period, all landing on the same invoice line and every interaction between them made explicit.
That is the engineering reality behind a strategic shift most SaaS pricing has not absorbed. The web app, with its sidebar nav and crowded settings page, was built for a human staring at a screen. A growing share of the traffic hitting commercial software comes from an agent acting on a person's behalf, talking to APIs, never loading a page — and pricing built when one human equaled one workload breaks in both directions. One customer routes an entire team's work through a single agent identity. Another fans the same work across hundreds of disposable instances. Counting either as "seats" produces a number that looks arbitrary to the buyer and unfair to the vendor.
Usage pricing is not new — three out of five SaaS companies already use some form of usage-based pricing (OpenView, 2023) — but metering a human's consumption and metering an autonomous caller's consumption are different problems, and the second one is arriving faster than the billing systems built for the first.
Why The Seat Was An Artifact
The per-seat model worked because the seat was a credible proxy. Software was bound to an interface, the interface to a person, and the person had finite hours inside the product. A vendor charging per seat was implicitly charging for a unit of human attention, and expansion revenue tracked headcount.
When the agent becomes the primary user, every link in that chain breaks. Agents do not load pages, so the interface stops being the binding constraint. An agent's appetite is bounded by compute cost rather than by a workday, so headcount stops correlating with consumption. A seat kept as the only SKU either underprices the heavy users into a denial-of-service problem or overprices the light ones out of the market. The seat was the unit that happened to be measurable, not the unit of value — and research on customer value in business markets (HBR, 1998) is unambiguous about the alternative: price should track value delivered, not the artifact of an interface. The willingness to pay has not gone anywhere either. Bessemer's cloud analysis (Bessemer, 2024) notes vertical AI companies already commanding roughly 80% of the contract value of the traditional systems they displace, which is a re-anchoring of what buyers pay for, not a collapse in what they will pay.
Three Pricing Layers Will Coexist
The post-UI pricing stack splits into three layers, each pricing a different kind of consumption. A vendor that picks one and ignores the others loses either the predictable revenue or the growth tail.
Seats With Embedded Usage
The seat does not disappear for humans. A finance analyst still needs predictable monthly access, and procurement still has to decide how many licenses to buy. What changes is what the seat entitles the buyer to: a modern seat has to include a meaningful default allowance of API calls and agent-mediated actions, because the human now reaches the product through an agent as much as through the UI.
Price the seat at the old rate and meter agent access aggressively on top, and customers route around it. The buyer's expectation, shaped by the interoperability of the major agent ecosystems, is that the seat covers their agent reading and writing their own data — whichever assistant they happen to use. The seat becomes a license for the human, and for any agent acting on the human's behalf. When the ratio of API to UI sessions per seat inverts, the bundled allowance is doing most of the value delivery, and the seat price has to be re-justified against that.
Agent Seats For Stateful Work
Some agents are not extensions of a single human. They run continuously, hold their own workspaces, write their own data, and carry permissions distinct from any user. A research agent maintaining a long-running investigation, or a support agent that owns a queue and escalates only on rare conditions, behaves more like a teammate than a tool, and charging for it as a feature of someone else's seat understates what it is.
The hard problem is that agent seats do not normalize across customers. One enterprise consolidates all its agentic work into a single high-throughput identity; another runs a thousand narrow agents for the same total volume. Pricing both at "one seat" undercharges the consolidator; pricing both at "a thousand seats" punishes the customer with the cleaner architecture. Keep the agent seat as a coarse entitlement SKU and meter the actual work in the next layer. The test for whether something has earned a seat: it persists across deployments, it owns artifacts, and access to it has to be granted and revoked like a team member's.
Consumption For Headless Autonomy
Above the seat allowance, and for any agent acting on its own initiative, consumption pricing is the only stable model — and the unit of metering is the whole question. A platform metering per API call risks pricing the wrong thing, because an autonomous agent can replace a multi-step human workflow with a single high-value request. Two calls with the same name can carry wildly different value.
This is where outcome-priced endpoints appear: rather than pricing a "create record" call at a flat rate, the vendor exposes a higher-level operation that completes an entire workflow — open the case, gather context, write the resolution, notify the right people — and prices it as one transaction. Guidance on agent design (Anthropic, 2024) argues for exactly that consolidation at the technical level; the pricing consequence is that the vendor charges for a result rather than a verb. The billing engine underneath is the part nobody budgets for, and it is the part that decides whether finance trusts the invoice: minimums, caps, and category rules interact, and a billing system that gets those interactions right is a build, not a configuration screen.
graph TD
A["Human User"] --> B["Seat With Embedded Usage"]
C["Stateful Agent"] --> D["Agent Seat"]
E["Autonomous Agent"] --> F["Consumption Per Call"]
B --> G["Overage"]
D --> G
F --> H["Outcome-Priced API"]
G --> H
style A fill:#1a1a2e,stroke:#16c79a,color:#fff
style B fill:#1a1a2e,stroke:#16c79a,color:#fff
style C fill:#1a1a2e,stroke:#0f3460,color:#fff
style D fill:#1a1a2e,stroke:#0f3460,color:#fff
style E fill:#1a1a2e,stroke:#ffd700,color:#fff
style F fill:#1a1a2e,stroke:#ffd700,color:#fff
style G fill:#1a1a2e,stroke:#0f3460,color:#fff
style H fill:#1a1a2e,stroke:#16c79a,color:#fffThe price should track the workload, not the interface that used to be the bottleneck.
When Seats-Only Pricing Still Works
The argument has boundaries. High-touch professional tools, where the value is anchored in a specific human's judgment and an agent is at best a note-taker, can hold the seat model longer than most. The product is the person. Adding consumption pricing where agents are not substituting for human work buys billing complexity with no revenue on the other side.
Regulated markets are the second case. Where every outcome has to be traceable to a named human decision-maker, an outcome-priced endpoint that abstracts away who did what creates a compliance problem the pricing page cannot see. The seat stays useful precisely because it ties activity to an identifiable person, and consumption pricing gets layered in only for traffic that carries no attribution requirement.
First Steps
- Measure the ratio of API traffic to UI sessions per active customer over the last quarter. If API traffic is growing faster than seat count, the seat is being subsidized by under-metered agent usage, and the subsidy has a size you can calculate.
- Draft one outcome SKU for your highest-value workflow: the inputs, the boundary of the work, and the price a customer would accept for the result — independent of how many internal calls it takes.
- Write down the interactions before the metering. Minimums, caps, allowances, and category toggles produce the invoice bugs, and the ones that erode finance's trust are interactions, not arithmetic.
Price The Workload, Not The Login
The shift is from charging for access to charging for work. Seats stay useful for human predictability, but the revenue line has to grow with the agent traffic that already carries most of the value the customer extracts. Long-term research on intangible investment and productivity (NBER, 2018) finds visible revenue lagging operating changes by years, which cuts both ways: a pricing model chosen now is a bet that pays out slowly, in whichever direction it was pointed.
If the surface of what a product should charge for has expanded faster than the current model can describe, that is a scoping problem and not a finance exercise — and the cheapest way through it is one written recommendation rather than a quarter of internal debate. An AI scoping session settles which units of work the customer actually values, what the metering has to capture, and what the first build is, for $750 credited against the work if it goes ahead. It is also where the answer is sometimes don't build it: a major US TV network came to ML LABS holding a quote for a full software system to serve a workflow that did not need one, and the session's deliverable was that it should not be built.
"Omar delivered in two weeks what our team estimated would take six months. The scoping session alone saved us from a $200K mistake." — AI Program Manager, a major US TV network
The pricing question does not arrive alone. For a first AI candidate rather than a pricing model, how to find the use case worth doing is the companion piece, and the economics driving all of it — cheaper production, more systems, more things to meter — are covered in why cheaper software creates more demand for engineers.
References
- Anderson, J. C., and Narus, J. A. Business Marketing: Understand What Customers Value. Harvard Business Review, 1998.
- Anthropic. Building Effective Agents. Anthropic Engineering, 2024.
- Brynjolfsson, E., Rock, D., and Syverson, C. The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. NBER Working Paper Series, 2018.
- OpenView Partners. The State of Usage-Based Pricing. OpenView, 2023.
- Bessemer Venture Partners. State of the Cloud 2024. Bessemer Atlas, 2024.
