How AI Agents Are Priced

By Brian Tr · Updated Oct 5, 2026

An AI agent is priced by choosing a unit of work and a price for that unit. That sounds simple. It isn't, because an agent isn't a login. It acts on its own, it can finish more work than a person in the same hour, and each task can cost you a different amount to run. Every one of those facts puts pressure on the pricing model that software has used for twenty years.

This guide walks through why seats struggle with agents, the main models founders use, how to choose the unit you bill on, and what to do when an agent fails, escalates, or finishes only part of a job. It also covers the cost floor underneath every price, and the questions buyers ask before they sign. It stays on mechanisms. Where it gives numbers, they come from investor and analyst research, and it names the sample behind each one.

Why agents break seat pricing

A seat price assumes one person uses the product and gets a roughly fixed amount of value from it. Three things about agents undo that assumption.

Agents replace or extend labor. A seat-based tool makes a person faster. An agent can do the task itself. Sequoia's March 2026 essay on services as the new software states the contrast in one line: a copilot sells the tool, an autopilot sells the work. If the buyer is paying for work, then headcount is the wrong yardstick for your invoice.

Agents act without a human in the loop. When nobody is sitting at a keyboard, there's no natural count of "users." One agent can run around the clock across thousands of cases. Charging per seat either undercharges you badly or forces you to invent a fake seat for software.

Cost per task varies. Classic software costs almost nothing to serve once it's built. An agent calls models and tools every time it works, so each run carries a real bill, and that bill moves with how hard the task was. Bessemer's February 2026 pricing playbook makes the same point: every AI query incurs real compute costs, which is why it treats pricing as a financial decision and a strategic one.

The data shows the move away from seats is already happening, though unevenly. In Kyle Poyar's State of B2B Monetization survey of 240 software and AI companies, run in April and May 2025, seat-based pricing fell from 21 percent to 15 percent of respondents over twelve months, while hybrid pricing rose from 27 percent to 41 percent. The typical respondent was a US company with $1 million to $20 million in ARR, so read it as a signal from younger software companies, not a census. For the seat side of this story in more depth, see per-seat pricing in the AI era.

The main ways agents are priced

Most agent pricing falls into six families. Real products often combine two.

1. A per-agent "digital employee" fee

The buyer pays a flat monthly fee for each agent they deploy, framed like a hire. "One support agent, one finance agent." It's easy to explain and easy to budget, and it borrows the buyer's mental model of headcount.

The risk is the same one seats carry: usage varies a lot between customers, and a flat fee doesn't move with it. Your heaviest account pays the same as your lightest, and your cost doesn't. Per-agent fees work best when you can bound the workload an agent handles, for example by capping volume or complexity inside the plan.

2. Per task, action, or conversation

Here the buyer pays for each unit of activity: a document processed, a record enriched, a conversation handled. Bessemer calls this workflow-based pricing and describes the logic well: booking a meeting, analyzing a spreadsheet, or drafting a contract are discrete units customers recognize, and they can estimate the time they save.

The catch is variance. Bessemer notes that one spreadsheet analysis might need ten times the compute of another. Per-task pricing works when the range of task difficulty is narrow enough that your average margin holds. When it isn't, you add tiers by complexity.

3. Per outcome or resolution

The buyer pays only when the agent finishes the job to an agreed standard: a ticket resolved, a claim recovered, a lead qualified. This is the most aligned with value, and the most demanding to run. We cover the trade-offs in depth in usage-based vs outcome-based pricing for AI, so the short version is enough here: you carry the cost of every attempt, including the failures, in exchange for a price the buyer finds easy to justify.

Bessemer's framing is that moving from consumption to workflow to outcome pricing means accepting more cost risk in exchange for tighter alignment with customer value.

4. Credit pools

The buyer buys a block of credits, and each agent action burns some number of them. A simple task might cost one credit and a heavy one might cost twelve. Credits let you charge different amounts for different work without publishing a price for every action, and they give the buyer one number to budget. They also hide the real price, which invites distrust if the burn rates aren't transparent. We go deeper in credit-based pricing for AI products.

5. Platform fee plus usage

A fixed subscription covers access, support, and a baseline, and usage is billed on top. Poyar's survey describes several versions of this. A platform fee plus usage works well when the usage metric is getting commoditized or doesn't capture the product's full value. A three-part tariff puts some usage inside a larger subscription fee, which gets the customer hooked and tends to raise consumption. A platform fee plus a success bonus looks like a normal subscription, with extra payment only if the customer gets better ROI than expected. The mix of all of these is covered in hybrid pricing for AI products.

6. Labor-budget-anchored pricing

Instead of pricing against other software, you price against what the work costs today. Bessemer lists "cost of hiring an equivalent FTE or market rate for the service provider" among the charge metrics for AI-enabled services. Sequoia gives the logic a number: a company might spend $10K a year on accounting software and $120K on an accountant to close the books. That gap is the room you have to price in. Charge a fraction of the labor cost you replace and the buyer still comes out ahead, while you're no longer fighting for a software line item.

This approach works only if you can show the labor you replace. If the agent merely helps a person, the buyer will compare you to other tools.

The models side by side

None of these wins by default. The pricing metric should match what your buyer already measures and what your costs track.

Choosing the billable unit

The unit you bill on matters more than the price attached to it. A good one passes four tests.

It's measurable. Both sides can count it from logs without arguing. "Tickets closed without a human reply" is countable. "Customer happiness" isn't.

It's attributable. The buyer agrees the agent did the work. If a result depends on a customer's own sales team or market conditions, you'll spend every invoice cycle in a dispute. Poyar's survey writeup frames this with the CAMP test for outcome pricing: outcome consistency, attribution, measurability, and predictability. Consistency asks whether all customers value the same outcome. Attribution asks whether buyers will give you credit. Measurability asks whether you can report it in real time. Predictability asks whether the result is stable across customers.

It's valued by the buyer. Customers don't think in tokens. Bessemer puts it bluntly: customers think about problems solved and work completed. Technical buyers who want granular control, like developers building on an API, are the exception.

It correlates with your cost. If your unit is cheap to serve in some cases and ruinous in others, your margin will swing. Choose a unit where the spread of cost per unit is manageable, or tier it so the expensive cases cost more.

A useful exercise is to list what the agent produces, give each output a unit price, and write down the proof that each unit happened: an event ID, a timestamp, the account, and the evidence. If you can't fill in the proof column, the unit isn't ready to bill.

Handling failures, escalations, and partial work

Pricing a perfect run is easy. The hard part is the rest, so decide these rules before the first contract, not after the first dispute.

Failures. If the agent errors out or produces output the buyer rejects, who pays for the compute? Under outcome pricing you do. Under per-task or credit pricing, the buyer usually does unless you say otherwise. Many vendors choose a middle path: no charge for runs that fail outright, normal charge for runs that complete but get rejected on a stated quality standard.

Escalations. When the agent hands a case to a person, did it resolve the case? Usually not. Define whether an escalated case counts as a billable unit, a reduced-rate unit, or no charge. Some founders bill a smaller "assisted" rate, because the agent did part of the work and gathered context for the human.

Partial completion. A claim half processed or a document drafted but not filed sits in between. Either break the job into stages with a price per stage, or define "complete" tightly enough that partial work is free. Stages can be easier to defend than a single large unit.

Caps and floors. Poyar's survey notes that pay-as-you-go with a cap is increasingly seen with outcome-based models where outcomes are unknown in advance. A spend cap gives the buyer a ceiling, and a monthly minimum gives you a floor.

The cost floor under every price

Whatever model you pick, your price must clear what each unit costs to deliver. That cost has several layers.

• Inference. The model calls themselves, which grow with the length of the task and the number of reasoning steps.
• Tool calls. Each search, lookup, or action the agent takes through another system may carry its own fee or rate limit.
• Retrieval and memory. Fetching documents and holding context adds cost per task.
• Review. If a human checks a share of outputs, that labor is part of your cost to serve.
• Retries and failures. The compute you spend on runs that don't produce a billable unit.

Add them up per unit, and compare to your price to see the gross margin on each billable unit. Our explainer on unit economics walks through the arithmetic, and the build-side levers for reducing the cost itself are in AI agent cost optimization.

Margins are a real constraint in this market. ICONIQ's 2026 State of AI report, based on a survey of 300-plus software executives, reported AI product gross margins of 45 percent in 2025, with a projected 53 percent in 2026 and 59 percent in 2027. Those are survey-based figures and projections from builders, and they average across many product types. Still, they tell you the starting position: if your price leaves you far below those levels, test whether the unit or the price is wrong.

Key Facts: Pricing AI Agents

• In a survey of 240 software and AI companies (April to May 2025), hybrid pricing rose from 27 to 41 percent of respondents in a year, while seat-based pricing fell from 21 to 15 percent (Growth Unhinged).
• 5 percent said outcome-based was their primary model, and 25 percent expected it to be by 2028 (same survey).
• ICONIQ's 2026 report found consumption-based pricing rose from 35 to 42 percent in six months, and outcome-based from 18 to 23 percent; companies blend 1.7 pricing models on average.
• Bessemer (February 2026) describes three charge metrics: consumption, workflow-based, and outcome-based, each trading cost predictability for value alignment.
• For every dollar spent on software, six are spent on services (Sequoia, March 2026). That is the budget labor-anchored pricing aims at.
• The CAMP test for outcome pricing: consistency, attribution, measurability, and predictability.

What buyers ask in procurement

Expect these questions before a contract is signed, and have the answers written down.

"What exactly am I charged for?" Give a one-sentence definition of the billable unit and an example invoice. Poyar's writeup notes that as hybrid models get more complicated, buyers don't necessarily trust what they see on a website and want to talk to a real person.

"What's the most I can be billed in a month?" Finance teams want a ceiling. Bessemer reports that enterprise buyers, especially CIOs and CFOs, want to allocate set budgets for technology, and that adoption can wane if teams can't name a fixed number. Offer a cap, a committed tier, or a pooled allowance.

"How do I verify the usage?" Provide an audit trail: event ID, timestamp, account, and the evidence that the unit was delivered. Buyers who can inspect the meter dispute less.

"What happens when the agent gets it wrong?" Show the failure, escalation, and partial-completion rules you chose above.

"What does it replace, and what does that cost today?" This is the labor-anchored question. Come with a baseline and be honest about what the agent doesn't cover. Bring the numbers, not adjectives.

"What happens to my price when your costs drop?" Models get cheaper over time, and sophisticated buyers know it. Decide in advance whether you pass savings through, hold the price and widen your margin, or add capability at the same price. Each is defensible if you've thought about it.

Start with a hypothesis

Treat the first price as a hypothesis. ICONIQ's report found that companies are blending an average of 1.7 pricing models, a reminder that few teams get it right with one model on the first attempt. For how pricing sits inside the wider set of revenue choices, see AI startup business models, and for a plain definition of what these systems are, see how AI agents work.

Related Reading

• Usage-Based vs Outcome-Based Pricing for AI
• Per-Seat Pricing in the AI Era
• Credit-Based Pricing for AI Products
• Hybrid Pricing for AI Products
• AI Agent Cost Optimization
• AI Startup Business Models