.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.
How to Price AI Agents Based on Skill Complexity the Complete Guide for SaaS Executives
A sales copilot that drafts an email, a coding agent that opens a pull request, and a service agent that resolves a return may all use the same underlying models. Yet they should not carry the same price structure. One helps an employee work faster. Another performs a defined piece of work. A third may replace an entire interaction that would otherwise require a person.
The distinction matters because SaaS executives are now making a permanent commercial choice. Price a capable agent like a feature, and the vendor leaves money on the table as autonomy rises. Price an assistive product like outsourced labor, and adoption stalls before customers see value. Price everything through tokens or credits, and the company ties its revenue to a cost base that competitors and model providers will keep pushing down.
Monetizely's position is clear: the primary meter for an AI agent should shift from the user to the completed unit of skilled work when the agent can finish a bounded workflow with little human intervention and the result can be verified. For those agents, the strongest architecture is a platform fee plus an outcome fee, with the completed outcome - not inference cost - as the primary meter.
Skill complexity changes what a buyer believes they are purchasing
“Skill complexity” does not mean the number of parameters in a model or the length of an agent prompt. It means the level of work the customer can safely hand over. A tool that suggests language in a contract is useful, but a lawyer still owns the work. An agent that reviews a standard contract against approved fallback clauses and routes only exceptions upward has taken on a defined professional task.
Buyers see that difference immediately. They buy assistive software as access for employees. They buy delegated work as capacity. They buy autonomous work as a business result.
The pricing implication follows. A seat is a sensible meter when the employee remains the center of production. A completed work unit becomes stronger when the agent is the center of production and the human becomes an approver, exception handler, or auditor.
Exhibit 1: The commercial anchor changes as agents take on more of the work
| Level of agent skill | What the human still does | What the customer is buying | Primary meter that fits | Example of a billable unit |
|---|---|---|---|---|
| Assistive | Creates the work, makes most decisions, and owns the final result | Faster individual productivity | Named seat | Licensed employee per month |
| Delegated but reviewed | Assigns work, reviews material outputs, handles exceptions | Extra capacity for a team | Seat with controlled usage overage | Active developer using an agent |
| Autonomous within one workflow | Defines policies, monitors results, handles edge cases | Completed work | Verified outcome | Resolved support case |
| Autonomous across several workflows | Sets operating rules, controls access, reviews performance | A managed operating capability | Platform fee plus verified work units by use case | Completed claims review, approved account update, resolved service case |
The table shows why “per agent” is rarely a durable answer. An agent is not a stable economic unit. One support agent may close 500 simple cases a day; another may handle 20 complex cases that require several systems and multiple policy checks. The customer does not value the existence of the agent. The customer values the skilled work it completes.
The market has not settled on one meter. Current public pricing shows per-seat, per-resolution, consumption, and subscription models operating at the same time. That variation is useful evidence, but it should not be mistaken for proof that each model is equally strong for every type of agent. Microsoft, Cursor, Cognition, Intercom, and Salesforce have each selected a structure that reflects the role their products play and the uncertainty they still need to manage.
Exhibit 2: Public agentic pricing models in market as of September 3, 2026
Several lessons emerge from these rate cards.
First, the flat subscription has not disappeared. Cursor and Devin use subscriptions to lower the barrier to entry and create predictable monthly spend. Neither vendor, however, treats the subscription as a promise of unlimited high-cost work. Cursor documents separate usage pools and on-demand charges after included use. Cognition’s April 2026 change also made clear that heavier use would move beyond included quota.,
Second, the cleanest outcome pricing appears in customer service because the event is observable. Intercom can define a resolution, a procedure handoff, a disqualification, and a qualified lead. The customer can inspect each event after the fact. That makes the commercial promise concrete: pay when the agent delivers the defined result.
Third, Salesforce demonstrates the appeal and the risk of broad platform pricing. Agentforce offers credits, conversations, user licenses, and flat-fee access. That flexibility can help a large installed base adopt agents, but it also asks the buyer to navigate several meters. A SaaS executive should treat that complexity as a warning: multiple billing options are not a substitute for choosing a primary value story.
The Agentic Monetization Spectrum separates assistive AI from skilled digital work
The central question is not whether an agent uses tools, retrieves data, or appears autonomous in a demo. The question is how much work the customer can hand over. The Agentic Monetization Spectrum (AMS) answers that question across three dimensions: zero-human ability, operational domain, and output/cost ratio. As explained in Monetizing Agentic AI, zero-human ability measures how much human involvement remains; operational domain measures whether the agent performs a narrow task, a full workflow in one function, or work across functions; and output/cost ratio asks whether the value created rises only with compute or rises far faster than it.,
A low zero-human score supports seat pricing because the employee remains the productive anchor. A high score creates room for output pricing because the agent performs the work. Operational domain determines whether a buyer sees the product as a tool, a role, or a broader operating capability. The output/cost ratio determines how much pricing should move away from compute. When value rises much faster than cost, compute is a margin guardrail, not a customer-facing price.
For practical use, score each dimension from 1 to 3:
- Zero-human ability: 1 means the human performs more than half the work; 2 means the human delegates and reviews; 3 means the agent completes the work with less than 20% human involvement.
- Operational domain: 1 means one task; 2 means an end-to-end workflow in one business function; 3 means work across functions.
- Output/cost ratio: 1 means cost and output rise together; 2 means output materially outpaces cost; 3 means output far outpaces cost.
Exhibit 3: AMS scores explain why the same meter should not govern every agent
The score is not a mechanical pricing calculator. It is a discipline for preventing a common error: treating all AI as a new kind of seat-based SaaS because most software has historically been sold that way.
Microsoft 365 Copilot scores low on zero-human ability despite its broad domain. Employees still decide what to ask, judge the response, and act on it. Microsoft’s $30-per-user monthly model therefore fits the product’s commercial role.
Cursor and Devin sit in the middle. Both can perform meaningful coding work, but software engineering still requires human judgment around architecture, security, test coverage, deployment, and product intent. Cursor’s paid-seat structure with extra usage and Devin’s quota or usage-based structure reflect a cost profile that remains closely tied to the work performed.,,
Fin scores differently. A customer who receives a correct answer, completes a return, or is routed through an approved procedure has received a finished service event. Intercom’s $0.99 outcome meter is not merely a billing choice. It reflects the fact that the agent can finish a bounded workflow without a person handling the interaction.
A score of seven or more earns an outcome meter
Monetizely’s practical threshold is an AMS score of seven or higher, provided the vendor can define and audit the completed result. Below that threshold, companies should avoid calling the product “outcome priced” merely because it has a credit balance or consumption line item.
A coding agent may open a pull request, for example, but a pull request is not necessarily a completed engineering outcome. It may fail tests, introduce a security issue, duplicate existing work, or sit unreviewed for weeks. Billing per merged pull request may become appropriate for a narrow, repeatable class of maintenance work. Billing for every proposed pull request would create disputes and encourage the wrong behavior.
The same standard applies in other functions:
- A support agent can be billed for a resolved case only if the resolution definition excludes a customer reopening the issue within an agreed period.
- A collections agent can be billed for a payment arrangement only if the arrangement meets stated policy rules and is accepted by the customer.
- A security agent can be billed for a remediated alert only if the remediation is completed, logged, and reversible.
- A sales-development agent should not be billed simply for sending emails; a qualified meeting or accepted opportunity is closer to the customer’s economic result.
The goal is not to find the most sophisticated meter. The goal is to find a unit that a CFO, operations leader, and frontline manager all recognize as real work.
Exhibit 4: The best primary meter follows the agent’s AMS position
The table makes a crucial distinction. A platform fee can be part of the answer, but it should not become a disguised seat price. Its job is to pay for the persistent value that exists before the first outcome occurs: the secure environment, integrations, controls, reporting, and administrative access. The outcome fee should pay for the skilled work the agent completes.
Cost still matters. It matters more in agentic AI than in traditional SaaS because a small group of heavy users can create substantial inference, tool, and runtime costs. Yet cost should set the floor, not define the customer’s understanding of value.
A compute-linked meter has an unavoidable commercial weakness. As model routing improves, cheaper models become capable, caching expands, and vendors optimize agent paths, the cost of delivering a given task falls. If the customer-facing rate is tied tightly to that cost, the vendor must either lower price over time or defend a growing markup on a unit the customer never wanted to buy.
An outcome meter works differently. A customer values a resolved service case because it avoids wait time, labor cost, churn risk, and poor customer experience. None of those benefits disappear because the vendor finds a cheaper way to run the agent.
Exhibit 5: A falling cost base weakens cost-plus pricing but strengthens outcome economics
| Direct cost per completed work unit | Price at a 5x cost-plus multiple | Price at a $0.99 outcome rate | Gross margin at $0.99 outcome rate |
|---|---|---|---|
| $0.20 | $1.00 | $0.99 | 80% |
| $0.10 | $0.50 | $0.99 | 90% |
| $0.05 | $0.25 | $0.99 | 95% |
The implication is straightforward: a cost-plus model forces the vendor’s revenue per unit toward the falling cost curve, while an outcome model allows the vendor to preserve a share of the customer’s stable economic gain.
That does not authorize arbitrary outcome prices. A vendor earns outcome pricing through reliable performance, clear definitions, auditability, and a result customers can verify without a billing argument. Where those conditions do not exist, compute-linked pricing is honest. Devin’s use of quota and usage is commercially rational while a software task can vary sharply in scope, runtime, and required human review.
The strategic mistake is treating that interim structure as the end state. As reliability rises and the product narrows toward repeatable classes of work, the vendor should migrate its primary story from “how much agent effort did we consume?” to “how much skilled work did we complete?”
The platform fee should pay for readiness while the outcome fee pays for work
Enterprise buyers need predictable budgets. They also need confidence that agent access, data handling, escalation paths, and reporting will work across teams. A pure outcome price can make a CFO nervous during the first year of deployment, especially when usage patterns are unknown.
The answer is not to retreat to seats. The answer is to separate the recurring value of the platform from the variable value of completed work.
A platform fee should cover capabilities that must exist whether the agent resolves ten cases or ten thousand. The variable fee should cover work that occurs only when the agent performs it.
| Platform fee should cover | Outcome fee should cover | Keep out of the primary customer-facing meter |
|---|---|---|
| Secure access, administration, integrations, policies, reporting, and support | Verified resolutions, completed reviews, approved transactions, or other defined work units | Tokens, prompts, model calls, retries, and internal agent steps |
| Initial operating capacity for agreed workflows | Volume above the committed included amount | The number of agents created or named |
| Ongoing access to controls and analytics | Results delivered within the agreed service definition | Model-provider cost changes |
The division protects both sides. Customers gain a known base commitment and a clear connection between added spend and added value. Vendors retain a durable revenue base without claiming that a login is the source of agentic value.
Salesforce’s published options show why this structure is increasingly important. Its Flex Credits can support broad consumption, while user licenses and other access options can support predictable deployment. The commercial task for a SaaS leader is to simplify that flexibility into one clear promise for each segment and use case.
A pricing metric cannot be chosen in isolation. Monetizely’s 5-Step Pricing Framework starts with goals and segmentation because a startup trying to win adoption has different needs from an established vendor trying to protect a large installed base. It then moves to packaging, where the offer must match the buyer’s needs rather than merely list agent features. Only then does the company choose the pricing metric, set the price points, and operationalize the model through product telemetry, billing, sales rules, and customer reporting. This sequence matters because a perfectly designed outcome meter will fail if the wrong segment receives it, the package includes irrelevant features, or the billing system cannot explain a disputed charge.,,,,
For agentic products, the five steps create a practical order of decisions.
Goals and segmentation determine whether the near-term priority is broad adoption, higher expansion revenue, margin protection, or enterprise credibility. A developer tool sold to individual engineers may need a low-friction subscription. A service agent sold to large contact centers may justify a committed platform agreement because the buyer needs integrations, controls, and an implementation plan.
Packaging determines what the customer is actually entitled to use. Enterprise buyers should not have to buy the same autonomy, model access, and workflow breadth as a small team. A strong package separates basic assistive work from higher-value autonomous workflows.
Metric selection comes next, using the AMS score. Price points come after the unit is clear. Operationalization comes last, but it cannot be an afterthought. A vendor must capture the event, apply the definition consistently, make the charge visible to customers, and give sales teams a defensible answer when an exception occurs.
Executives should build toward the work unit they want to own
The durable prize is not higher token revenue. It is the right to own a recognized unit of skilled work in the customer’s operating model.
That requires patience. Many agents will begin as assistive products because the technology, trust, or data access is not ready for autonomy. Others will remain seat-based because employees use them as general tools across too many tasks to define a fair outcome. Those cases should not be forced into an outcome story.
But when an agent can complete a bounded workflow, the company should move decisively. The buyer is no longer purchasing faster access to software. The buyer is purchasing finished work.
Choose the work category your company intends to own over the next three years. Define it in customer terms, such as resolved service cases, completed compliance reviews, or accepted maintenance changes, rather than in product terms such as prompts, runs, or agents.
Set an explicit AMS migration trigger for every agent offering. Decide in advance what level of autonomy, workflow reliability, and auditability must be reached before the product moves from seat or usage pricing to a completed-work meter.
Create a commercial owner for outcome definitions. Product, finance, customer success, and legal should share one contract-ready definition of what counts, what does not count, and how disputed events are reviewed.
Use cost data to set floors and controls, not the customer promise. Monitor model, tool, and runtime costs at the workflow level, but protect the external price from routine changes in inference cost.
Organize packages around customer operating maturity. Offer assistive access for early users, controlled workflow capacity for teams, and a platform-plus-outcome architecture for enterprises ready to delegate real work.
Footnotes
- https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- https://www.getmonetizely.com/monetizing-agentic-ai-book-saas/the-agentic-monetization-spectrum
- https://www.microsoft.com/en-us/microsoft-365-copilot/enterprise
- https://cursor.com/pricing
- https://cursor.com/docs/models-and-pricing
- https://cognition.com/blog/new-self-serve-plans-for-devin
- https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes
- https://www.salesforce.com/agentforce/pricing/