Opinion
Who pays when an AI agent tries again?
"When customers pay for results, an AI agent's extra attempts can eat into the seller's margin," writes Stigg CEO Dor Sasson. "Deciding when to stop also means deciding what service the customer receives."
Sell a customer a resolved support ticket, and the customer knows what they are buying. The AI company providing it has a harder calculation. One ticket might need a short answer from a model. Another might send an agent through several tools and failed attempts before it finds a solution. The selling price can stay the same while the cost of delivering it rises with every step.
A company can account for every credit a customer uses and still lose money on the service. If a resolved ticket carries a fixed charge, another attempt increases the cost without increasing the agreed price. It may also be the attempt that earns the payment by finally solving the problem. The seller has to weigh that chance against the expense of continuing.
At New Relic, my team worked on a model that helped engineers find relevant logs during an incident. Customers valued it, but we lacked the infrastructure to turn that use into revenue. The company's move to usage-based pricing exposed how difficult that infrastructure was to build, and helped lead me to co-found Stigg. AI agents make the problem more immediate: a single task can keep consuming resources long after the customer has agreed to a price.
Consider the difficult ticket again. The agent is nearing the seller's budget for resolving it. Stopping would contain the cost, but leave the customer without the result they came for. The company needs to decide whether to fund more work, hand the issue to a person or tell the customer it cannot complete the task. How much another attempt costs also depends on which model handles it.
Stripe's agreement to acquire OpenRouter puts model routing alongside payments infrastructure. OpenRouter routes requests across models according to factors including task complexity, price and speed. Stripe says the combination will help businesses manage revenue and costs together. A higher-priced model may complete a task in fewer attempts and reduce the total cost of delivering a result. Engineers need room to make that switch while preserving the customer's agreed pricing rules.
For example, a customer might buy credits redeemable for completed tasks. Resolving one ticket then deducts a fixed number of credits, regardless of how many model calls it takes. The seller tracks the cost of those calls separately from the customer's balance.
Keeping those balances correct brings responsibilities familiar from banking: recording what has been used, reserving credits for work in progress and releasing unused reservations. That is what I mean when I describe AI companies as accidentally building banks.
Imagine two support agents handling different tickets for the same customer. The shared balance covers either ticket, but not both. If both agents check it before either reserves the credits it needs, both can be authorized to proceed. Checking the balance and reserving credits must happen as a single operation, so the second agent cannot use credits already committed to the first. By the time a later billing process spots an overrun, the resources have already been consumed.
Before launch, I would examine the cost of successful resolutions and failed attempts, using difficult cases as well as straightforward ones. Product and commercial teams can then decide how much variation the price can support, and translate that judgment into task budgets and rules for retries or handoffs. The software has concrete instructions to enforce while the agent works. A retry under a fixed-price agreement does not by itself justify another customer charge. Under a usage-based plan, further work may consume more of the customer's allowance, within the agreed limits.
An organization extending an AI service to more teams needs a way to keep one team's activity from exhausting everyone else's allowance. Team budgets and a record of where credits went let the buyer allocate access and check that spending stays within those limits. In my work on monetization, customers' trust in the reported usage is part of their willingness to keep using the product.
A seller may choose to absorb the cost of a difficult ticket, provided its pricing can support that across the service. What happens on the next attempt is part of the offer it sells. If the team has not decided when to continue, stop or hand over the work, it has left a commercial decision to whatever the code happens to do.
Dor Sasson is co-founder and CEO at Stigg.
