.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 Is Agentic Pricing Understanding the Next Frontier in Automated Pricing
The most important pricing question in AI is no longer, “Should we charge by seat or by usage?” The better question is, “What work is the customer delegating, and what proof of completion can both sides trust?”
That distinction matters because agentic products do more than assist employees. They can investigate a customer issue, update a CRM record, write and test code, route a qualified lead, or resolve a support case. When software performs work that once required a person, a seat is often no longer the clearest unit of value. Yet charging for every token, model call, or agent step simply shifts the vendor’s cost structure onto the customer.
Monetizely’s position is clear: agentic pricing should charge primarily for the unit of work the agent completes, not for the AI behind it. Seats remain appropriate when a human is still the center of the workflow; usage credits fit when work is variable but results are hard to verify; outcome pricing becomes the right primary meter only when the result is clear, attributable, and valuable.
Agentic pricing changes the question from access to completed work
Agentic pricing does not mean using AI to change prices automatically. It means pricing software that can take action on a customer’s behalf.
Traditional SaaS pricing usually sells access. A company pays for 100 CRM seats because 100 people need the system. An agentic product may instead handle 20,000 support conversations, complete 400 code tasks, or process 5,000 invoice exceptions. The customer’s attention shifts from “How many people can log in?” to “How much work did the product reliably complete?”
The market already shows four distinct responses to that shift. As of September 8, 2026, Cursor combines a per-user subscription with included model usage and on-demand overages. Devin offers individual subscriptions and team plans with included capacity and on-demand credits. Intercom charges for Fin based on completed outcomes. Salesforce offers both action-based Flex Credits and conversation-based pricing for Agentforce.
Exhibit 1. The billing unit changes as the product takes on more of the job
| Product | What the buyer is primarily acquiring | Primary commercial model as of September 8, 2026 | What the meter is trying to capture | Source |
|---|---|---|---|---|
| Cursor | Faster work by an individual developer or engineering team | $20/month individual plan; $40/user/month Teams, with included and on-demand model usage | Access, productivity, and expensive model consumption | |
| Devin | Agent capacity for software work | Free, Pro at $20/month, Max at $200/month, and Teams from an $80/month minimum | Agent work capacity, with guardrails for variable compute use | |
| Intercom Fin | Resolved customer questions and completed workflows | $0.99 per support outcome; higher-priced sales qualification outcomes | A verified result in a customer interaction | |
| Salesforce Agentforce | Actions or customer-facing conversations across a broader platform | $500 per 100,000 Flex Credits, or $2 per conversation | A portable unit of agent activity across use cases |
The pattern is not a march away from subscriptions. It is a move toward the meter that best reflects the work the customer is buying.
Cursor is a useful counterexample to the belief that every AI product needs outcome pricing. A developer still directs the work, reviews the output, and decides whether to merge code. The product improves the developer’s productivity, but the human remains the accountable worker. A user-based subscription therefore remains legible, while included usage and on-demand spend protect Cursor from runaway inference costs.
Intercom Fin sits at the other end of the range. When Fin answers a question or completes a configured procedure and the customer does not need more help, Intercom can define and measure a billable outcome. As of July 30, 2026, its published rules count only one outcome per conversation, and later follow-up requests can reverse an assumed resolution. That design makes the commercial promise more credible because the company has stated the condition under which it will not charge.
The five decisions must precede the rate card
A pricing metric rarely fails because the finance team selected the wrong number. It fails because the company chose the number before deciding what business it is building.
Monetizely’s 5-Step Pricing Framework puts the decisions in their necessary order: goals and segmentation, packaging, pricing metric, price points, and operationalization. The sequence matters. A company first decides which customers it intends to win and what business goal pricing must support. It then builds offers that match those buyer groups, chooses the unit it will bill for, sets the rate, and finally builds the systems that can meter, invoice, and govern the model. In Monetizing Agentic AI, we argue that the metric is the hinge: everything before it makes the choice possible, and everything after it makes the choice real.[^1]
Consider a customer-service agent sold to three groups:
- A digital-native startup may want a self-serve agent that handles common questions in one channel.
- A mid-market company may need an agent connected to its help desk and order-management system.
- A global enterprise may require voice, email, chat, audit logs, approval rules, custom integrations, and contractual service levels.
One generic “AI Agent” plan will force the startup to buy enterprise features it will not use or force the enterprise into a package that cannot support its operating requirements. Pricing will then appear to be the problem, even though the real failure began with segmentation and package design.
Cursor’s public offer shows the more disciplined approach. Its individual plan addresses the developer’s need for personal productivity, while team and enterprise offerings add centralized billing, administration, privacy controls, SSO, pooled usage, invoice billing, and more advanced security controls. The core coding value remains recognizable across tiers; the surrounding controls change with the buyer.
Devin’s April 14, 2026 revision points in the same direction. Cognition retired the earlier Core and Team structure in favor of Free, Pro, Max, Teams, and Enterprise, explicitly describing the change as a clearer path from testing to regular use. Its current Teams plan also separates predictable full seats from free flex seats that draw against shared on-demand credits.
The lesson is straightforward: the package should reflect the buyer’s operating need, while the meter should reflect the agent’s work. Mixing those two decisions creates plans that customers cannot understand and sales teams cannot defend.
Autonomy, domain, and value creation reveal the right meter
The Agentic Monetization Spectrum, or AMS, offers a practical way to determine how far a product should move from seat pricing toward output or outcome pricing. It evaluates an agent on three dimensions.
First, zero-human ability asks how much human work remains. At the low end, the human performs the work and the AI assists. In the middle, the human delegates and reviews. At the high end, the agent completes the work with limited human involvement. Second, operational domain asks whether the agent performs a narrow task, a full workflow within one function, or work across several functions. Third, the output/cost ratio asks whether value rises roughly with the cost to serve, rises faster than cost, or greatly exceeds cost.
The more autonomous the agent becomes, the broader the work it performs, and the greater the customer value relative to compute cost, the stronger the case for moving beyond a seat. The score does not mechanically dictate a price model. It narrows the range of credible choices.
Exhibit 2. AMS points each product toward a different primary meter
| Product | Zero-human ability | Operational domain | Output/cost ratio | Monetizely assessment | Best primary meter |
|---|---|---|---|---|---|
| Cursor | Medium | Medium | Inflecting | Human review remains central; the buyer still sees a developer productivity tool | Active user, with included and on-demand model usage |
| Devin | Large | Medium | Inflecting | The agent can execute software tasks, but task complexity and compute use still vary sharply | Agent capacity or usage credits tied to work performed |
| Intercom Fin | Large | Medium | High | A resolved support interaction has direct operational value and can be measured | Verified outcome |
| Salesforce Agentforce | Medium | Large | Inflecting | The platform spans many business uses, where one universal outcome would be hard to define | Action credits, with conversation pricing for customer service |
The table explains why “outcome pricing” is not a blanket prescription. Fin can charge for outcomes because a support resolution can be defined, observed, and linked to a customer interaction. Salesforce must support service, sales, employee, and workflow use cases across a broad platform, so an action-based credit gives it a more portable meter. Salesforce’s current offer reflects that reality: Flex Credits price each action at $0.10, while external customer conversations are available at $2 each.
A coding agent presents a harder case. A task may produce a merge-ready pull request, a partial draft, a failed test run, or useful research that still needs a human engineer to finish it. Charging for “a completed coding task” before quality and attribution are reliable invites disputes. Devin’s present model is therefore more credible as a capacity-and-usage model than as a pure outcome model. Its published enterprise documentation still describes billing in Agent Compute Units set by the order form, while current self-serve plans use included quota and on-demand credits.
The strongest agentic price metric is not the most sophisticated one. It is the one a customer can forecast, audit, and challenge without ambiguity.
A support vendor cannot simply say, “We charge for value.” It must define whether a resolved ticket means the customer clicked “thanks,” stopped replying, accepted a refund, received a tracking number, or completed a workflow that handed the case to a person. Each definition changes the economics and the perceived fairness of the offer.
Intercom’s Fin documentation provides a useful benchmark. It distinguishes among resolutions, procedure handoffs, disqualifications, and sales qualifications. It also prices them differently: $0.99 for a support resolution or procedure handoff and $9.99 for a qualified sales lead, as of July 30, 2026.
Before committing to an outcome meter, operators should test the commercial conditions behind it.
Exhibit 3. A clear result is necessary before an outcome can become a price unit
| Test | Strong answer | Weak answer | Commercial implication |
|---|---|---|---|
| Can both parties define success? | “The customer’s issue was resolved under stated rules” | “The agent was helpful” | Weak definitions should not support outcome pricing |
| Can the vendor measure it automatically? | Event logs show the workflow and final state | A manager must review every case | Use action or usage billing until measurement improves |
| Can the result be attributed to the agent? | The agent executed the key steps and the result occurred | Many teams and systems contributed | Avoid charging for an outcome the agent did not clearly cause |
| Does the customer receive value quickly? | A support case, qualified meeting, or payment exception is completed | Value appears months later | Consider a task or activity meter instead |
| Can the customer forecast spend? | Historical volumes and contract limits exist | Demand is volatile and unmeasured | Add commitments, caps, and alerts before scaling |
The implication is demanding but useful: a company should not announce outcome pricing until its product telemetry can defend every invoice line.
A vendor may still use a fixed fee around an outcome meter. The outcome must remain the primary commercial unit, while the fixed component pays for platform access, integrations, support, or a committed volume. That architecture gives buyers a budget baseline without disconnecting revenue from the work performed.
Agentic products often make one mistake repeatedly: they package technical capability rather than buyer need. A plan called “Advanced Agent” tells a prospect little. A package designed for “high-volume customer support across three channels with audit controls” tells the buyer what problem it solves.
The following package design makes the commercial logic visible before the sales conversation reaches price.
Exhibit 4. Agent packages should separate operating needs, not merely restrict model access
| Buyer group | Core job to be done | Package design | Primary meter | Essential commercial protection |
|---|---|---|---|---|
| Individual professional | Test whether the agent improves personal output | Low-commitment plan with clear included capacity | User or modest usage allowance | Spend limit and transparent overage notice |
| Functional team | Add capacity to an existing team workflow | Shared workspace, admin controls, integrations, pooled usage | Task capacity or shared credits | Team budget and role-based permissions |
| Enterprise function | Standardize an agent across a governed workflow | Security, audit logs, custom integrations, service support | Committed usage or verified outcomes | Minimum commitment, service terms, and usage reporting |
| Customer-facing operation | Resolve high volumes of repeatable external requests | Workflow configuration, quality controls, escalation rules | Verified resolution or qualified result | Clear definitions, exclusions, and dispute process |
The table does not argue for more tiers. It argues for purposeful differentiation. A startup buying an outbound sales agent does not need enterprise territory rules. A bank deploying an agent across regulated support channels cannot buy the same offer with fewer credits.
Harvey and Sierra illustrate the strategic choice at the top of the market. An enterprise-only offer can be rational when the company intends to win a narrow premium segment with deep implementation and custom terms. The mistake arises when leaders claim to serve the wider market while offering no credible path for smaller buyers to evaluate, adopt, or expand.
Teams often begin their agentic pricing work with a rate card. Should a resolution cost $0.99, $2, or $5? Should an agent credit cost $1 or $10? Those are important questions, but they arrive fourth, not first.
Once the segment, package, and metric are clear, rate setting becomes a disciplined trade-off among market adoption, customer ROI, and gross margin. The price should leave the customer with a visible gain after paying for the software. It must also leave the vendor enough room to serve heavy users, fund implementation, and improve the product.
Cursor’s pricing shows why a single rate rarely captures the full economic story. Its $20 monthly individual plan provides access and included usage, while customers who use frontier models more heavily can buy additional usage. That structure keeps entry accessible for lighter users without forcing the vendor to subsidize unlimited expensive inference.
A practical operating view requires leaders to watch the economics at the level of completed work, not just revenue per account.
Exhibit 5. Agentic pricing needs a weekly operating dashboard, not a quarterly billing review
| Measure | Why it matters | Warning sign |
|---|---|---|
| Agent runs by customer segment | Shows where adoption is real | Heavy usage concentrates in a segment the package was not built for |
| Successful outputs or verified outcomes | Tests whether the meter matches delivered value | Usage rises while completed work does not |
| Cost per successful output | Connects model expense to customer value | A few complex workflows erase margin |
| Human override or escalation rate | Reveals how autonomous the product actually is | Outcome pricing is ahead of product reliability |
| Invoice disputes and credit requests | Tests whether customers accept the metric | Sales must explain charges that product data cannot explain |
The dashboard turns pricing into a management system. Without it, companies learn about a broken meter only after customers complain, margins fall, or renewals stall.
Agentic pricing is often described as a strategy problem. It is also a systems problem.
A company must record the event that triggers a charge, apply the right contract rule, show the customer what happened, prevent duplicate charges, cap spend when required, and reverse charges when the defined result is undone. Intercom’s reversal of assumed resolutions after a customer returns with an unresolved issue shows the level of precision required.
Salesforce makes the same point from a platform perspective. Its Digital Wallet supports consumption tracking across Flex Credits and conversation-based pricing, while its published buying models include prepaid, committed, and pay-as-you-go options. A pricing model becomes easier to scale when the customer can see the remaining balance, understand what consumed it, and choose the right commitment level.
The operating requirement is not administrative overhead. It is part of the product promise. A customer that cannot explain a charge internally will not expand an agent, regardless of how much the product may help.
Monetizely’s position is therefore not that every agent should charge by outcome. The position is more exact: price the delegated work at the highest level of value that can be measured, attributed, forecast, and defended. For an assistive tool, that may remain the active user. For a compute-heavy autonomous worker, it may be capacity or usage credits. For a reliable customer-facing agent with a clear end state, it should be the verified outcome.
Operators should build pricing around the work they intend to own
Choose the company’s strategic boundary before choosing the meter. Decide whether the product will serve a narrow enterprise workflow, a broad self-serve market, or a defined path between the two. Pricing cannot compensate for an unresolved market choice.
Set a formal trigger for moving from seats or credits to outcomes. For example, require a documented success definition, automated event capture, a dispute process, and a stable human-escalation rate before changing the primary meter.
Make pricing telemetry a product requirement. Treat event logs, usage controls, customer dashboards, and invoice explanations as features that ship with the agent, not as finance work added later.
Use early contracts to learn where the real value appears. Compare buyer expectations with actual task volumes, completion rates, cost per output, and renewal behavior before standardizing a public rate card.
Assign one executive owner for the full pricing loop. Product, finance, sales, customer success, and engineering should share the same definition of a billable event and the same evidence for whether the model is working.