Pricing an Agent Product When Your Costs Are Variable

Software pricing assumes near-zero marginal cost. Agent products break that assumption: one customer's usage can cost a hundred times another's on the same plan, and the expensive ones are frequently the ones getting the most value — which is to say, the ones you least want to discourage.

Every pricing model handles this differently, and the failure modes are predictable.

What makes agent costs unusual

Per-task cost varies by orders of magnitude. A simple question is a couple of model calls; a complex investigation is forty, each re-sending a growing context. The distribution has a long tail, and the tail is most of your bill.

Cost isn't visible before the work. You can't quote a price for a task without doing it, which rules out clean per-task pricing for open-ended work.

Your costs change under you. Model prices fall, your prompts get longer, a new feature adds turns. Margins move without any pricing decision being made.

Value doesn't track cost. The cheapest interaction might save an hour; the most expensive might produce nothing. Cost-plus pricing prices the wrong thing.

The models and how each fails

Per seat. Familiar, predictable for the buyer, and it decouples revenue from cost entirely — which is the problem. A power user costing many times an average one pays the same, and heavy adoption on a fixed-seat plan is indistinguishable from a margin problem.

Works when usage per person is naturally bounded — the agent assists a workflow someone does a bounded number of times a day. ⚠️ Fails when the agent can be pointed at unbounded work, where one customer's batch job eats the plan.

Per task or per run. Aligns revenue with cost, and it's honest. Two problems: the buyer can't predict their bill, which procurement dislikes; and it penalizes exploration exactly when you want people forming a habit.

Works when tasks are homogeneous enough that per-task cost is stable, and when the value of one task is legible ("one processed invoice").

Per token or per call. Maximum alignment, minimum comprehensibility. Customers can't reason about it, can't forecast it, and feel punished by improvements that make the agent more thorough. Reasonable for developer-facing infrastructure; poor for a product with business buyers.

Outcome-based. Charge for the resolved ticket, the completed migration, the qualified lead. Best alignment with value, and the hardest to operate: you need an agreed definition of the outcome, attribution when a human helped, and enough margin to absorb runs that produce nothing. Also inverts your incentives usefully — you now want the agent to be efficient, not busy.

Seats plus included usage. What most products converge on, for good reason. A seat price with a generous usage allowance, overages beyond it. Predictable for typical customers, protected against the outlier, and the allowance is a lever you can tune per segment.

✅ What to do regardless of model

Instrument cost per customer from day one. You cannot price what you can't measure, and retrofitting attribution loses the history you'd need. Cost per tenant, per feature, per completed task.

Know your cost distribution, not your average. Price against p95, not the mean. A model that works on average and loses money on the top decile is a model that loses money as you grow, because the top decile grows fastest.

Build the efficiency levers before you need them. Turn budgets, model routing on cheap steps, caching, and context trimming are margin controls. Teams that build them under pressure build them badly.

Make heavy usage visible to the customer. A usage dashboard turns a surprise into a conversation, and it lets a customer self-manage rather than discovering an overage at renewal.

💡 The margin trap worth naming

Quality improvements often increase cost — more turns, more verification, more thorough investigation. Under a fixed-price plan, every quality improvement reduces margin, which creates a quiet institutional pressure against making the product better.

Notice this pressure explicitly rather than letting it operate through a thousand small decisions. If your pricing punishes quality, that's a pricing problem, not a reason to ship a worse agent.

The takeaway

Agent economics don't match software economics: marginal cost is real, variable, and heavy-tailed. Instrument per-customer cost immediately, price against the tail rather than the average, and prefer a model with a usage component so revenue moves with cost. Seats plus included usage is the pragmatic default. And watch whether your pricing quietly makes quality expensive — that's the failure that compounds.