AI Agent Pricing: How to Price Agents Without Losing Your Margin

Pricing an AI agent is harder than pricing software, for one reason. Software costs almost nothing to run, so any price above zero earns margin. An agent spends real money every time it works. Each task triggers model calls, tool calls and sometimes a human review, and that cost changes from one task to the next.

So AI agent pricing has two jobs. It has to capture the value the agent creates, and it has to stay above a cost line that moves. Most pricing pages we review do one of these and ignore the other. This guide covers both.

Why seat pricing breaks for agents

A seat price assumes a person logs in and does the work. An agent does the work without a person in the seat. If the agent replaces three support staff, the customer needs fewer seats, so your revenue falls exactly when your product delivers the most value.

Seats also hide cost. A simple support ticket might cost three cents in model spend and a messy one a dollar fifty. A seat charges both the same. Heavy users drain your margin while light users subsidise them, and you cannot see it until the bill arrives.

The four AI agent pricing models

Per task or per run. The customer pays each time the agent completes a defined unit of work: a document processed, a call handled, a report drafted. It is easy to understand and tracks your cost closely. It works when tasks are similar in size. It struggles when one task can be ten times the work of another.

Credits or usage. The customer buys a pool of credits and the agent draws them down. It protects your margin because heavy work burns more credits. The risk is that buyers cannot translate a credit into work they recognise, so they cannot forecast the bill. If you use credits, publish what a credit buys in plain terms.

Outcome-based. The customer pays for a verified result: a resolved ticket, a booked meeting, a recovered payment. It is the most defensible model for agents because it prices the work, not the access. It needs a measurable result, an agreed baseline and a floor. Our outcome-based pricing guide covers the requirements in detail.

Hybrid: platform fee plus usage or outcome. A fixed monthly fee covers access and baseline volume, and a variable charge applies above it. This is what we recommend for most agent products. The floor covers your delivery cost and gives finance a predictable line item. The variable part captures upside as the customer grows.

Model your cost per task first

Before you set a price, know what one unit of work costs you. Not the average task, the expensive one. Agents make many model calls per task, and each call often carries more context than the last, so cost climbs as the work goes on. Teams estimate cost in testing and then watch margin thin in production.

Take a sample of real tasks and measure four things: model tokens in and out, tool and API calls, retries and failures, and any human review time. Find the cost at the 90th percentile, not the median. That number is your floor. Your price per unit should sit well above it, and your contract should include a fair-use limit for the tasks that run far past it.

Model prices also move. Build a right to reprice on notice into enterprise contracts, so a change in your provider's rates does not become your customer's windfall and your loss.

Choose the value metric buyers can forecast

The value metric is the unit you charge for. For agents it is the most important pricing decision you make, more important than the price itself. We test every candidate with the ACE framework. Can the customer audit what they paid for? Does revenue rise when your cost rises? Is it easy to bill and easy to predict?

Tokens pass the cost test and fail the other two. Seats pass the ease test and fail on cost. A metric close to the outcome, such as resolved tickets or processed invoices, usually passes all three. When the outcome cannot be measured cleanly, use the closest usage proxy and put it inside a hybrid. The usage-based pricing guide explains how to choose and structure that proxy.

A worked example

An agent handles tier-one support tickets. Measured cost per ticket is 18 cents at the median and 90 cents at the 90th percentile. A resolved ticket costs the customer about 6 dollars of loaded staff time.

Per seat pricing would lose money on the busiest accounts. Pure token pricing would leave buyers unable to forecast. We would price it as a platform fee of 1,500 dollars a month including 1,000 resolutions, then 1.20 dollars per resolution above that, with a fair-use limit on ticket length. The customer pays a fifth of what the work used to cost. The floor covers infrastructure and oversight. Margin holds at the 90th percentile, and revenue grows with every ticket the agent takes on.

Set the number with research, not guesswork

Once the structure is right, test the price with real buyers. Use Van Westendorp to find the acceptable range, then Gabor-Granger to find where revenue peaks inside it. Both guides include a free calculator you can use with your own survey data.

Common mistakes in AI agent pricing

Pricing from cost alone leaves most of the value on the table, because the customer compares your price to the work you replace, not to your model bill. Copying a competitor's credit system copies their confusion too. Launching without a floor hands your cost base to the customer's usage habits. And repricing the whole customer base at once turns a pricing change into a churn event. Launch the new model on new business first, run both side by side for a quarter, then migrate.

The test of good agent pricing is simple. The invoice explains itself, the customer can predict it, and your margin holds when usage doubles.