Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
A founder sees a small model bill and assumes an agent service will have excellent margins. Then the first customers arrive. Some need onboarding help, some submit unusual files, and some generate repeated failures that require manual review. The model remains inexpensive, but the business does not.
Pricing should begin with contribution margin: revenue less the variable costs required to serve the customer. It should then account separately for fixed operating costs, acquisition, and cash timing. This article offers an illustrative framework, not a market price recommendation or an earnings forecast.
Choose the real unit of work
Define a verified successful task. It might be an approved invoice record, a correctly routed ticket, or a completed scheduling job. Avoid using a model call as the main business unit when one customer task can require several calls and still fail.
Track attempts, retries, failures, and human interventions. Divide total task-related cost by verified completions to understand the economics of delivering the promised result. A low cost per attempt can hide an expensive failure rate.
Keep customer value and provider cost separate. The customer may value a fast outcome far above its technical cost, but willingness to pay still needs validation. A cost model tells you whether a price is sustainable; it does not prove that the market will accept it.
Build the full variable-cost stack
Include model usage, external tool fees, storage, retrieval, document processing, communication channels, and payment processing where applicable. Add review labor, customer support, and incident work that grows with usage or customer complexity.
Measure labor realistically. If a reviewer spends three minutes investigating an exception, the cost is not just the seconds needed to approve the final answer. Include context switching, correction, and documenting the result when those are necessary to operate the service.
Account for unsuccessful work. Customers should not necessarily be charged for provider-caused failures, but the provider still bears their cost. The price of successful tasks must support an honest failure and recovery process.
Work through an illustrative account
Suppose a customer pays US$1,000 per month. Direct platform and tool usage costs US$180, review labor costs US$220, customer support costs US$100, and payment-related fees cost US$30. The account contributes US$470 before fixed overhead, acquisition costs, taxes, and other expenses.
That US$470 is not net profit. If the business spends US$12,000 a month on fixed salaries, software, and administration, it needs sufficient combined contribution to cover those costs. Founder time also deserves an explicit treatment rather than being assumed free indefinitely.
Now increase the exception workload. If review labor rises to US$500, contribution falls to US$190 with no change in subscription revenue. This sensitivity is why a service should monitor review rate and complexity rather than only token consumption.
Design the price and limits together
A base fee can cover readiness, integrations, and a minimum level of support. Usage charges can reflect work that scales. Complexity tiers or specialist-review charges may be appropriate when some tasks predictably require more effort, provided the distinctions are clear before purchase.
Avoid unlimited plans until you understand the usage distribution. Heavy users, repeated retries, and large documents can make a flat price unprofitable. Limits should be understandable business units, not obscure technical restrictions discovered only after a customer pays.
Stripe's usage-based billing documentation is a technical reference for implementing metered models. The choice of billing platform does not determine the right commercial unit; that comes from the service's value, costs, and customer expectations.
Stress-test the bad month
Model a provider outage, a surge in volume, a new document format, and a customer requiring unusually heavy support. Estimate the cost of handling the situation responsibly. A business that is profitable only when nothing goes wrong has not priced its actual obligations.
Include refunds and credits in the model. If the service fails to deliver, honoring a reasonable remedy affects cash and contribution. Do not assume every invoice is collected in full or immediately.
Consider concentration risk. One large account may look attractive but demand bespoke support or represent most of the business's revenue. A loss or usage spike can have a disproportionate effect. Evaluate account economics alongside overall customer mix.
Validate quality while optimizing cost
Cost reductions are useful only if the service still meets its quality and authority requirements. A cheaper model may generate more retries, review, or rework. A faster workflow may omit evidence needed to verify completion.
Use representative tasks and inspect final outcomes, as discussed in the linked evaluation guidance. Compare total cost per acceptable result rather than isolated inference prices. Keep separate metrics for critical errors that should not be traded away for savings.
Review prices with evidence
During a pilot, track actual cost by customer and task category. Compare it with the assumptions used to quote the service. If a category consistently loses money, investigate whether the workflow, scope, or price needs to change.
Discuss changes transparently with customers and honor existing commitments. A sustainable agent business needs enough margin to maintain quality, respond to incidents, and keep improving. Token markup alone rarely captures that responsibility.
Keep a simple cost dictionary so the same expense is not counted twice or omitted between teams. Reconcile the operational model with actual invoices and time records periodically; otherwise a carefully designed spreadsheet can drift away from the business it describes.
Sources and research note
Stripe usage-based billing. Demystifying evals for AI agents. Research checked October 26, 2026. Product behavior and prices can change. Business examples and proposed prices in this article are illustrative unless explicitly attributed.
Leave a Reply