What is AI agent monetization?
It means charging for the finished work an AI agent does, instead of charging for a tool that a person uses to do the work. It may look like a simple pricing choice, but it changes the whole business. The company stops acting like a software publisher selling licenses and starts acting like a utility, where customers pay for what they use.
Two things changed at once, and conflating them is why pricing discussions go in circles.
| Dimension | Conventional software | Agentic software |
|---|---|---|
| Unit of value | A person using it. More seats, more value | Work completed. Headcount stops correlating with anything |
| Marginal cost | Near zero. One more user costs you almost nothing | Real and per-action. You pay for the tokens before you invoice for the result |
| Who the buyer is | A budget holder buying tools for a team | Frequently the same person, with procurement built entirely around seats |
The second row is the one that reorganises everything. Conventional software scaled beautifully because usage was free to serve, so the only question was what a customer would pay. With agents there is a second question underneath it: what it costs you to deliver what they just consumed.
Why does per-seat pricing break?
Seats stop correlating with anything worth billing for. An agent exists precisely so the work proceeds with nobody operating it, which means a customer extracting more value may have fewer staff logging in, and the contract then bills them a smaller amount the better things go.
Three failures, and the third is the one that shows up in a renewal conversation.
- Value and headcount move in opposite directions. The better the agent, the fewer people needed to supervise it. Your pricing then falls as your value rises, which is an unusual position to design into a contract deliberately.
- One seat can generate unbounded cost. A single user pointing an agent at a large backlog consumes more than a hundred users opening dashboards. Per-seat pricing caps your revenue and leaves your costs uncapped.
- It prices the wrong thing to the buyer too. A customer being asked to pay per person for something that replaced the need for people will notice, and that objection arrives at renewal rather than at signature.
Per-seat is not dead, and it survives for a specific reason worth naming. It is the only model most procurement functions can process without a new approval path, so it frequently persists as the contracting wrapper while the real commercial logic sits in usage commitments underneath it.
What are the pricing models?
Four in practice, and most mature offerings end up combining two. The honest framing is that each solves one problem and creates another, so the question is which trade-off suits your cost structure and your buyer's procurement rather than which model is correct.
Each with what it fixes and what it breaks.
- 01
Per seatFixes: procurement friction, because every finance function already understands it. Breaks: the link to value, and leaves your costs uncapped against a capped price.
- 02
Per action or per taskFixes: alignment, since revenue tracks work done. Breaks: the buyer's ability to forecast, which leads to rationing, and a customer rationing your product is not adopting it.
- 03
Consumption, usually token-basedFixes: margin, because the price moves with the cost. Breaks: the abstraction, since you are now explaining tokens to a buyer who wanted an outcome, and exposing your cost structure while you do it.
- 04
Outcome-basedFixes: everything about alignment. Breaks: measurability, because both parties must agree what the outcome was and whether your agent caused it. This is where the contracts get long.
The common landing point is worth stating because it is rarely presented as a model in its own right. A platform fee that covers your fixed costs, plus a usage component that covers your variable ones, plus a cap that protects the buyer. It is less elegant than outcome pricing and it survives contact with both a CFO and a procurement team.
What is the margin problem nobody prices?
The agent decides what each job costs while it runs, not by you at the design stage. Traditional software had steady costs and revenue that grew with sales. Agents flip this. Revenue is fixed by the contract, but the cost of serving it moves up and down depending on how efficiently the agents work. Two identical jobs can cost very different amounts, and that gap comes straight out of your profit.
Four consequences, and the first is the one that catches a growing business out.
- A successful customer can be a loss-making one. Under any fixed or capped price, the customer who adopts most enthusiastically consumes most. Enthusiasm becomes a margin event rather than a renewal signal.
- Retries and loops are pure gross margin. An agent that fails and repeats has consumed twice and delivered once. This is not an edge case, it is the largest invisible line in most token bills.
- Your margin depends on engineering decisions. Which model serves which step changes your cost of goods directly, so model routing stops being an efficiency exercise and becomes a commercial one.
- You cannot price per customer without measuring per customer. If spend cannot be attributed to the account that caused it, you are pricing on an average and discovering the distribution later. See LLM cost attribution.
The number to compute before choosing any model. Cost to serve one completed unit of work, including the runs that failed and the ones that repeated. Most providers know their total token bill and their revenue, and cannot state that figure per customer or per use case. Without it a pricing decision is a guess with a spreadsheet attached, and the gap between your provider invoice and your attributed total is where the answer is hiding.
How do marketplaces fit?
They solve distribution and billing, not monetization. An agent marketplace gives you discovery, a transaction mechanism and a measure of buyer trust, and it leaves every question on this page exactly where it was, because you still choose the model and still carry the variable cost.
What they genuinely provide, and what they do not.
- Discovery and trust. A buyer evaluating agents has no established way to assess an unknown provider. A marketplace borrows the host's credibility, which is the main thing being bought.
- Metering and collection. Consumption tracking and billing infrastructure you would otherwise build, which is a real saving for a smaller provider and the reason consumption pricing became practical at all.
- Procurement bypass. Frequently the largest benefit, since purchasing through an existing cloud commitment skips a vendor onboarding process measured in months.
- What they do not solve. Your cost of delivery, your margin, or what unit you charge in. A marketplace takes a percentage of a price you still had to set.
One structural point for anyone building on top of someone else's platform. Marketplace economics add a take rate to a margin that is already variable, so a model that works at a given price direct can be loss-making through a marketplace at the same price. The channel decision and the pricing decision have to be made together rather than in sequence.
How do you decide Agent Monetization?
Measure your cost to serve before you design a price, because every model on this page is a bet on that number. Providers reason from what the market will bear and discover their own unit economics afterwards, which is how an agreement that looked attractive becomes one nobody wants to renew.
Five steps, in the order that stops you repricing in year two.
-
Compute cost per completed unit of work
Per use case, including failures and retries. This is the foundation, it requires attribution rather than a total, and nothing else on the list is meaningful without it.
-
Find out how variable that number is
Not the average, the spread. If your most expensive customer costs eight times your median, a flat price is a bet on your customer mix staying as it is.
-
Ask what your buyer's procurement can actually process
Elegant pricing that cannot clear an approval process does not get bought. This frequently decides the contracting wrapper even when the commercial logic underneath is usage-based.
-
Put a cap or a commitment on both sides
A floor that covers your fixed cost and a ceiling that lets the buyer forecast. This is the compromise most mature agreements converge on, and designing it in is easier than renegotiating it.
-
Instrument before you launch, not after
Per-customer, per-agent consumption from day one. Retrofitting attribution to a live commercial agreement means repricing customers who have already signed, which is a conversation worth avoiding entirely.
One caution about outcome pricing, since it is where most of the enthusiasm currently sits. It is the right destination and a difficult starting point, because it requires an agreed definition of the outcome, a measurement both parties trust, and an answer to attribution when something outside your agent contributed. Providers that get there usually arrive after a year of usage data, not at launch.