.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
What Should Companies Charge for an AI Agent’s Work?
The right answer is not “per seat” and not always “per outcome.” Companies should price AI agents around verified units of completed work, then add a platform fee and outcome-based upside only where value is measurable, attributable, and within the vendor’s control.
AI agents create a pricing problem that ordinary software did not have to solve.
Traditional SaaS sells access: a user gets a seat, logs in, and uses a product. Cloud infrastructure sells consumption: a customer pays for compute, storage, or API calls. Human-services businesses sell labor: hours, projects, transactions, or performance. AI agents sit awkwardly across all three models. They consume variable compute, may replace or augment human work, and can sometimes deliver a concrete business result without a person touching the task.
That is why the market is moving beyond the familiar question—“What should this software cost per user?”—toward a more difficult one: “What is a completed unit of AI labor worth?”
The distinction matters. A chatbot that drafts a response is software assistance. An agent that identifies a customer, checks an order, applies a policy, issues a refund, records the action in a CRM, and closes the case has performed work. Charging merely for the chatbot’s existence understates its value; charging a percentage of every downstream business result can overstate the vendor’s contribution.
The strongest pricing principle for agentic AI is therefore this:
Companies should charge primarily for verified work performed—not for model tokens, not for a digital “employee,” and not for broad business outcomes they cannot credibly control.
The practical model is usually hybrid: a recurring platform fee to cover access, governance, integrations, and support; a variable charge for a verified task, workflow, resolution, or transaction; and, in narrowly defined situations, an outcome-based bonus or gain-share component. That structure matches the economics of the product, protects vendor margins from volatile AI costs, and gives customers a bill that maps to business value.
The market is already heading in that direction, though more cautiously than the rhetoric suggests. Orb’s 2026 review of 80 AI-agent companies found that 95% used hybrid pricing, 91.3% used a usage component, and 71.3% retained a subscription component. Pure outcome pricing, despite the excitement around it, appeared in only 3.8% of the sample.
That is the central reality of agent pricing: outcome pricing is the aspiration; hybrid pricing is the operational answer.
Why per-seat pricing breaks down when software does the work
Per-seat pricing was built for a world in which more users generally meant more value. A CRM vendor could charge per salesperson, an HR platform per employee, and a help-desk vendor per support representative. The buyer understood the budget. The vendor enjoyed predictable recurring revenue. And the software’s marginal cost of serving another user was usually low.
Agents invert that logic.
If an AI customer-service agent resolves a larger share of inbound cases, the customer may need fewer human support seats. If an AI coding agent completes more implementation work, the customer may produce more output without adding engineers. If an accounts-payable agent processes invoices autonomously, the number of employees using the interface may fall even as the volume of work rises.
A seat meter therefore creates two distortions:
It charges for human access rather than machine output. A company with 100 support representatives may derive far more value from an agent that closes 500,000 cases than from one that helps each representative write faster replies.
It can penalize adoption. If a customer’s goal is to automate a process, charging for more seats ties price to the very labor model the agent is meant to reduce.
That does not mean seat pricing should disappear. It remains appropriate for copilots—tools that make a specific employee more productive but leave that employee responsible for the work. GitHub Copilot is a useful example. GitHub charges organizations $19 per Copilot Business user per month and $39 per Copilot Enterprise user per month, while bundling AI credits and enabling additional usage-based charges.
This is sensible because the primary unit of value remains a developer’s enhanced productivity. The user is still in the loop, responsible for reviewing code and deciding what ships.
But GitHub’s packaging also reveals where the model is going. Its plans include credits, and advanced agents consume those credits based on model choice and task complexity; GitHub explicitly notes that a longer agent session across many files can cost more. The company is already operating a hybrid model: seat for access, consumption for expensive autonomous work.
As agents move from copilot to operator, pricing must move from seat to work.
The six pricing models—and where each belongs
There is no single universal meter for agents. The appropriate unit depends on the nature of the work, how variable execution costs are, how easy success is to verify, and whether the vendor controls enough of the process to take performance risk.
Best for: copilots, knowledge assistants, drafting tools, developer assistance, internal research tools, and software where the user remains accountable for every consequential decision.
Unit: named user, active user, or role-based license.
Strengths: simple procurement, predictable budgets, familiar SaaS mechanics.
Weaknesses: disconnects price from automation value; can produce “shelfware”; exposes vendors to unusually heavy agent usage unless limits or credits are added.
The key test is simple: Does the customer still need a person at the center of each workflow? If yes, per-seat pricing can work. If the agent completes cases on its own, it is increasingly the wrong primary meter.
2. Usage-based: charge for the resources consumed
Best for: horizontal agent platforms, developer tools, AI infrastructure, orchestration layers, and early-stage products whose customers want flexibility.
Unit: tokens, model calls, compute time, tool calls, API requests, storage, workflow steps, or credits.
OpenAI’s API pricing is a pure example of infrastructure economics. Its rate cards charge based on input, cached-input, and output tokens, with prices varying by model. OpenAI also cautions that a lower per-token rate does not necessarily lead to a lower total task cost because models may use different quantities of input, output, and reasoning tokens.
That warning is crucial for agent vendors. A one-shot chat request is relatively predictable. An agent can plan, call tools, retrieve documents, retry after errors, inspect outputs, and invoke a more capable model when uncertain. The cost of two apparently identical business tasks can differ radically.
Usage pricing protects margins because it passes this variability to the buyer. It is particularly appropriate when the vendor sells capability rather than a complete business process.
But buyers do not want to manage token economics. They do not buy a support agent because they want 100 million tokens; they buy it because they want fewer unresolved support cases. Tokens are a good cost meter, but usually a poor value meter.
3. Per-task: charge for a discrete, verified piece of work
Best for: bounded back-office workflows with an auditable completion state.
Unit: invoice processed, claim reviewed, document classified, account reconciled, report generated, employee onboarded, compliance file assembled, or code-review task completed.
Per-task pricing is often the best default for an autonomous agent because it is understandable and measurable. It answers the most important question: What did the agent actually do?
A task must be defined more carefully than “a prompt” or “a conversation.” A robust task has:
- a clear starting event;
- an agreed set of inputs;
- a completion state in a system of record;
- quality and escalation rules;
- an audit trail; and
- a rule for retries, reversals, and human corrections.
For example, “invoice processed” should not mean “the agent read an invoice.” It should mean that the agent extracted the required fields, completed defined validation checks, posted the invoice to the appropriate system, and routed exceptions according to policy.
This is the model most likely to become dominant in functions such as finance operations, HR operations, IT service management, procurement, and compliance. In these cases, the task itself is valuable, observable, and often more controllable than the eventual business outcome.
Best for: commerce, payments, bookings, onboarding, claims, collections, logistics, and other workflows where a business transaction is recorded.
Unit: order placed, booking completed, payment collected, subscription saved, shipment rerouted, claim settled, appointment scheduled, or account opened.
Transaction pricing is a specialized form of task pricing, but it deserves separate treatment because transactions generally have a direct economic footprint. If an agent completes a booking or processes a return, both parties can identify the event and reconcile it against a ledger or system of record.
Salesforce offers several variants of this approach through Agentforce. Its published pricing includes $2 per customer-facing conversation, $2 per help-agent resolution, and Flex Credits—priced at $500 for 100,000 credits—with standard actions consuming credits. The lesson is not that one Salesforce meter is universally superior. It is that agent platforms increasingly need more than one meter because interactions, actions, and resolutions carry different cost and value profiles.
Per-transaction pricing works especially well when the agent causes an irreversible or revenue-related action. But it needs careful safeguards. A vendor should not be rewarded simply because an agent processes more refunds, sends more collections messages, or creates more low-quality leads. The metric has to include quality thresholds and, in many cases, customer-approved rules.
5. Per-resolution or per-workflow: charge for completed end-to-end service work
Best for: customer service, IT support, employee service, and multi-step operational processes.
Unit: verified issue resolution, completed service request, successful procedure, or closed workflow without human intervention.
Customer support has become the proving ground for this approach because a resolution is close to a self-contained labor unit. An issue arrives; the agent investigates, acts, and either solves it or escalates it.
Intercom’s Fin AI Agent charges $0.99 for a qualifying resolution and defines one resolution as a case in which no further help is requested after the agent’s final answer. It also charges $0.99 for a procedure handoff or disqualification, and $9.99 for a qualified sales lead; only one outcome is charged per conversation.
Intercom’s logic is sound: a qualified lead is economically more valuable than answering a product question, so it commands a higher price. The company describes the approach plainly: “you pay when Fin delivers value.”
Zendesk has moved in the same direction. In May 2026, it said its AI-agent strategy would use outcome-based pricing and that every billed resolution would be verified both by the agent’s end-to-end handling and by an independent AI evaluation model; spam and routine exchanges are excluded.
Decagon offers customers a choice between per-conversation pricing and a higher per-resolution price, with the latter charging nothing for escalations. It reports that many customers still choose per-conversation pricing because it offers a more predictable and transparent bill.
That is an important caveat. A resolution is a better value metric than a conversation, but it is not automatically a better buying experience. If “resolution” is vague, disputed, or prone to vendor-friendly definitions, buyers may prefer the simplicity of a fixed per-conversation rate.
6. Outcome-based: charge for the economic result
Best for: highly repeatable use cases with clear attribution and an objective source of truth.
Unit: revenue recovered, conversion achieved, qualified opportunity accepted, fraud loss prevented, churn avoided, successful collection, or cost reduction verified against a baseline.
Outcome pricing is the most seductive model because it appears to align incentives perfectly. The buyer pays only when the vendor produces value. The seller has a direct incentive to improve performance. The “shelfware” problem largely disappears.
Sierra has made this model central to its positioning, arguing that customers should pay when its software achieves “specific, valuable outcomes.” It identifies examples such as resolved conversations, ecommerce purchases, saved memberships, upsells, and cross-sells, while also acknowledging that a blended consumption model can make more sense for simpler routing or greeting interactions.
This is directionally right—but outcome pricing should be used far more selectively than AI vendors often imply.
The reason is attribution. Consider a sales agent that produces a “qualified lead.” Did the agent create the value, or did brand awareness, pricing, product-market fit, a marketing campaign, and a human account executive do most of the work? Consider a churn-prevention agent: did it save the customer, or was the customer never going to cancel? Consider a fraud agent: how can the parties know which losses were truly prevented rather than merely flagged?
The more distant the commercial outcome is from the agent’s own completed work, the harder fair pricing becomes.
The best model: a three-layer price architecture
The most durable commercial design for an AI agent is neither a flat subscription nor a pure contingency fee. It is a three-layer price architecture:
This design separates three things that are often confused:
The platform fee matters because a serious enterprise agent is not merely an API wrapper. It needs role controls, integration maintenance, audit logs, testing, evaluation, prompt and policy management, human-escalation workflows, reliability engineering, and often implementation services. Those costs do not disappear in a month when task volume is low.
The verified-work fee should be the commercial core. It gives the customer a bill linked to actual throughput and gives the vendor a revenue stream that scales with adoption.
The outcome component should be limited to the portion of value the agent can credibly influence. A collections agent might charge a modest fee per compliant outreach workflow plus a percentage of incremental recoveries above a negotiated baseline. A support agent might charge per verified resolution plus a bonus for maintaining a customer-satisfaction score above an agreed threshold. A sales-development agent might charge per accepted qualified opportunity, not per raw meeting booked.
This is not merely a compromise. It is better economics.
How to calculate what the agent’s work is worth
Companies should not set agent pricing by taking a human salary, dividing it by annual tasks, and charging the customer 80% of the resulting amount. That is a tempting shortcut—and usually wrong.
The right starting point is the customer’s avoidable economic value, not the fully loaded cost of the person whose job appears adjacent to the agent.
A useful formula is:
Value per completed task = avoided labor cost + error reduction + cycle-time value + incremental revenue + risk reduction − residual human work − implementation and oversight cost
Each term needs discipline.
Avoided labor cost
The relevant figure is not always a job eliminated. In the early stages of deployment, AI value usually appears as avoided hiring, reduced contractor spend, lower overtime, increased capacity, or reassignment of employees to more valuable work.
For support, value can come from reduced contact volume and lower average handling time. McKinsey estimates that generative AI could create productivity value equivalent to 30% to 45% of customer-care function costs.
That does not mean the agent vendor should capture 45% of every support budget. It means there is room to price against a defensible fraction of realized value—after accounting for remaining human cases, agent-management work, quality controls, and the cost of the vendor’s platform.
Error reduction and risk reduction
In finance, healthcare administration, compliance, and insurance, the agent may create more value by preventing an error than by saving a few minutes of staff time. The economic value could include lower rework, fewer chargebacks, fewer policy violations, lower loss rates, and faster audit preparation.
But risk claims must be measured conservatively. Vendors should not charge for “errors avoided” unless there is a baseline and a credible counterfactual. In high-stakes environments, a better first step is to price verified work with quality guarantees and introduce outcome sharing only after enough historical data exists.
Faster work can matter even when it does not eliminate labor. An agent that resolves an account-access request in two minutes rather than two days may improve activation, retention, employee productivity, or customer satisfaction.
This is valuable, but it is easy to overclaim. A vendor should distinguish between a task completed faster and a business outcome caused by faster completion. The former is a reliable pricing unit; the latter may justify a performance bonus only where evidence supports it.
Incremental revenue
Revenue-linked pricing makes sense where the agent’s action is clearly proximate to conversion: an agent completes a booking, saves a subscription through an approved retention offer, or converts a qualified self-service buyer.
It makes less sense where the agent is merely one contributor to a longer sales process. In that setting, charge for an accepted sales-qualified opportunity or completed sales workflow—not a percentage of closed revenue six months later.
The most important design rule is:
Price the narrowest verifiable unit that captures most of the value without forcing the vendor to insure risks it does not control.
That produces a practical hierarchy:
This hierarchy also explains why pure outcome pricing remains relatively rare. Buyers like the promise, but vendors must carry unpredictable compute costs, implementation costs, behavior risk, and disputes over attribution. Orb’s data suggests that the market has not abandoned subscriptions or usage meters; instead, it is combining them.
Capgemini’s 2025 survey tells a similar story from the buyer side. Among 834 data and AI executives whose organizations preferred buying agents or working with providers to tailor them, 55% selected consumption-based pricing, 43% platform-based pricing, 37% license-based pricing, and only 17% outcome-based pricing. Respondents could select multiple options.
In other words, customers want value alignment, but they also want budget control.
Pricing must change as agents become more autonomous
An agent’s price should rise with autonomy—but not simply because the vendor labels it “more autonomous.”
Autonomy has economic meaning when the agent takes on more of the workflow’s responsibility: it handles ambiguity, uses more systems, performs consequential actions, resolves exceptions, and requires less human review. But greater autonomy also increases the cost of reliability, liability, monitoring, and insurance against failure.
A useful maturity framework has four stages.
Stage 1: Assistant
The AI drafts, summarizes, searches, or recommends. A human approves the result.
Best pricing: per seat, with usage caps or credits for premium models.
The AI can prepare work and take limited actions under a user’s supervision.
Best pricing: seat plus action credits, or seat plus workflow usage.
Stage 3: Supervised agent
The AI completes defined workflows and escalates exceptions. Human review is sampled or required only for certain thresholds.
Best pricing: per task, transaction, or verified resolution; platform fee; service-level and quality commitments.
The AI owns a measurable business process within agreed guardrails and can act across systems with limited human intervention.
Best pricing: verified-work pricing plus outcome upside, contractual performance guarantees, spending caps, and explicit liability boundaries.
The shift is not cosmetic. A stage-four agent is not worth more because it “reasons” longer. It is worth more because the customer can redeploy labor, reduce cycle time, or earn revenue with less supervision.
That means capability alone should not determine price. Transfer of responsibility should.
The margin problem: agents make cost-to-serve volatile
Agent pricing cannot be designed without cost discipline.
Unlike conventional SaaS, AI-agent workloads can be variable and spiky. A task may involve retrieval, tool calls, retries, lengthy context windows, evaluation checks, escalation models, or multiple agent handoffs. The same workflow may cost dramatically more when documents are messy, systems are unavailable, or the agent encounters an exception.
That is why vendors should never set a fixed per-outcome price before they understand the full cost of successful work:
Cost per successful task = model inference + tools + retrieval + orchestration + evaluation + human review + cloud infrastructure + support + failure/retry cost
The denominator matters: successful tasks, not attempts.
Model pricing alone is not enough. OpenAI’s documentation explicitly notes that lower token prices do not automatically produce lower overall cost because tokenization and generated reasoning can differ by model and task. An agent vendor that prices based on the clean, first-pass cost of a workflow can lose money once it absorbs retries, quality-control calls, and hard cases.
The answer is not to retreat to opaque token billing. It is to build internal cost controls while presenting customers with understandable work-based pricing:
- route routine work to cheaper models;
- reserve frontier models for difficult or high-value cases;
- cap agent loops and tool retries;
- define which exceptions are billable;
- use confidence thresholds and human escalation;
- set annual or monthly spend commitments;
- price unusually complex workflows separately; and
- include fair-use boundaries for pathological cases.
Customers should see a predictable bill. Vendors should see granular internal telemetry.
A good AI-agent price is not just a number. It is a measurement system and a risk-sharing agreement.
Before launch, buyer and vendor should agree on:
Zendesk’s decision to use independent evaluation for billed resolutions points to the future of this discipline: the value meter itself must be trustworthy.
The agent itself is not the product. The completed work is.
A company should not ask, “How much would a digital employee cost?” That framing invites misleading comparisons to salaries, ignores residual human oversight, and treats AI as a substitute for a person rather than a production system with its own cost curve and failure modes.
Nor should companies reflexively charge per token, per prompt, or per seat. Those meters describe consumption or access, not the customer’s reason for buying.
The right question is: What verified unit of work does the agent complete, what economic value does that work create, and how much risk can the vendor fairly assume?
For most serious enterprise agents, the answer will be a hybrid contract:
- a platform fee for the durable operating layer;
- a per-task, per-transaction, or per-resolution fee for completed AI work; and
- an outcome-linked bonus only where the vendor can measure and influence the result.
That model gives buyers a transparent path to ROI. It gives vendors a way to fund reliability, governance, and increasingly expensive autonomous capabilities. And it prevents the industry from repeating the central mistake of early SaaS: charging for software access even when the buyer really wants a business result.
AI agents are changing software from a tool employees use into a system that performs work. The pricing model must change with it.