Pricing traditional SaaS was relatively straightforward. A company built software for people, customers bought access to it, and pricing could often be tied to seats, plans, features or usage.
Agentic products complicate that logic because the software is no longer simply helping someone do the work. Increasingly, it is doing parts of the work itself.
An AI support agent can resolve a customer issue. A sales agent can research an account, qualify a prospect and recommend who should receive outreach. A finance agent can reconcile transactions. An operations agent can execute workflows across multiple systems.
When software moves from being a tool to becoming a participant in the work, the pricing question changes with it. The challenge is no longer simply deciding how much access to the product should cost. It is deciding what part of the work customers should actually pay for.
Start with the unit of value, not the pricing model
One of the easiest mistakes for an AI company is choosing the pricing mechanism before understanding what customers actually value.
Tokens are measurable. API calls are measurable. Agent actions are measurable. None of those automatically makes them good pricing units.
A customer using an AI support agent probably does not care how many tokens were required to solve an issue. They care that the issue was resolved without requiring a human support representative. A sales organization does not necessarily care how many model calls an agent made while researching an account. It cares whether that research creates a useful sales opportunity.
That distinction matters because the best unit of pricing is usually connected closely enough to customer value that the buyer understands why spending more should be acceptable.
This is already visible in the market.
Intercom currently prices Fin at $0.99 per outcome. For customer support, that can mean successfully resolving an issue rather than charging the customer for every AI interaction that happened along the way. Intercom explicitly says unsuccessful attempts are not billed as outcomes.
HubSpot has moved in a similar direction. In April 2026, it shifted its Breeze Customer Agent and Prospecting Agent toward outcome-based pricing. Customer Agent costs $0.50 per resolved conversation, while Prospecting Agent charges $1 when it recommends a lead for outreach. HubSpot described the philosophy simply: AI should increasingly be measured by outcomes rather than output.
These models are interesting because the pricing unit is beginning to resemble the job customers hired the software to perform.
But outcome pricing is not automatically the answer
It is tempting to conclude that every agentic product should simply charge for outcomes. In practice, defining an outcome can become difficult very quickly.
Consider an AI sales agent.
Is the outcome a researched account? A qualified lead? An email response? A booked meeting? A sales opportunity? Or closed revenue?
The further pricing moves toward the final commercial result, the more valuable the outcome becomes, but attribution also becomes harder.
A booked meeting might have been influenced by the agent, existing brand awareness, an outbound salesperson, previous marketing activity and the prospect already being in-market. Charging based on revenue sounds perfectly aligned with value until the customer and vendor disagree about who actually created that revenue.
The right outcome therefore needs to be valuable enough for the customer to care about, but measurable enough for both sides to agree that it happened.
Intercom's current model illustrates this distinction particularly well. A standard resolution, procedure handoff or disqualification costs $0.99, while a successful lead qualification costs $9.99. The unit changes in price because the commercial value of the outcome changes.
That is an important lesson for agentic companies: not every action performed by an agent has equal economic value.
Think about the work the agent is replacing or improving
Another useful starting point is to understand the economics of the work before deciding the price of the software.
Suppose a company employs people to process 10,000 support requests each month. An AI agent can autonomously handle 6,000 of those requests while humans manage the remaining complex cases.
The customer can now estimate the value fairly clearly. There is a known volume of work, a human cost associated with that work and a measurable level of automation.
The vendor does not necessarily need to charge a percentage of the employee cost being saved. But those economics provide a boundary for what the product can reasonably be worth.
The same thinking can be applied to other categories. A compliance agent might reduce hours spent reviewing documents. A finance agent might process reconciliations. A sales agent might research accounts that previously required SDR time. A security agent might investigate alerts that would otherwise require analysts.
Before asking, "What should we charge?" it is worth asking, "What does this work cost the customer today, and what changes economically once our agent performs it?"
That gives pricing a business foundation rather than simply benchmarking what another AI startup happens to charge.
There are several viable pricing models
Agentic products will probably not converge around one universal model. Different products create value in different ways, and the pricing model should reflect that.
A seat-based model can still work when humans remain the primary users and AI mainly improves their productivity. If the agent is effectively a copilot inside a workflow, charging for users can remain understandable and predictable.
An action or consumption model works better when agent activity varies significantly between customers. Salesforce, for example, currently offers Agentforce through several structures. Its Flex Credits model charges $500 per 100,000 credits, with individual agent actions consuming credits, while customer-facing agents can alternatively be priced at $2 per conversation. Salesforce also offers user-based options for some deployments.
An outcome model makes sense when the agent completes a clearly identifiable piece of valuable work. Support resolutions are an obvious example because the beginning and end of the job can be reasonably well defined.
A capacity or committed-usage model can work when enterprises need predictable budgets but activity fluctuates. Instead of receiving an unpredictable bill for every model call, the customer purchases a defined amount of agent capacity and uses it across the organization.
And in many cases, the right answer may be hybrid pricing: a platform fee that gives customers access to the infrastructure, combined with usage or outcome charges as agents perform more work.
The important point is that the pricing model should follow the nature of the value rather than whichever model is currently fashionable.
Pricing also needs to work when the agent gets better
There is a less obvious problem that AI companies need to consider.
What happens to revenue when your product becomes dramatically more efficient?
Imagine an agent initially needs 20 model calls to complete a workflow. Six months later, improvements in models and orchestration allow the same workflow to be completed with five calls.
If customers are charged for technical consumption, better engineering could reduce the vendor's revenue even though the customer receives exactly the same value.
Outcome pricing behaves differently. If the customer pays for a successfully completed workflow, the vendor benefits from making the underlying technology more efficient because the cost of producing that outcome falls while its customer value remains similar.
This is one reason pricing too close to tokens or compute can be dangerous. Those are important cost units for the vendor, but they are not necessarily durable value units for the customer.
A good pricing architecture should allow product efficiency to improve margins rather than punish the company for becoming more efficient.
Predictability matters more than many AI companies realize
Usage-based pricing creates another tension. Vendors like it because revenue expands as customers use more AI. Customers can dislike it for exactly the same reason.
An enterprise buyer needs to know whether an AI product is going to cost $50,000 next year or unexpectedly become a $300,000 line item because adoption accelerated.
This is why pricing cannot only optimize for value capture. It also needs to make the buyer comfortable adopting the product at scale.
Salesforce's Agentforce structure provides an interesting example. Alongside pay-as-you-go consumption, Salesforce offers pre-purchase and pre-commit structures that let customers establish usage commitments while still metering actual agent activity. Its Digital Wallet allows organizations to track consumption as agents operate.
For B2B AI companies, this suggests an important principle: customers should be able to understand what drives their bill before they deploy the agent widely.
If every additional automated workflow creates financial anxiety, the pricing model may eventually become a barrier to product adoption.
The price should make scaling the agent feel economically good
One useful test is surprisingly simple.
Imagine the customer doubles their use of your agent next year. Are they happy about that?
If the answer is yes because they are resolving twice as many tickets, processing twice as many transactions or generating significantly more qualified opportunities, the pricing model is probably connected to value.
If the customer starts trying to limit usage because every additional agent action feels like another unpredictable expense, the pricing architecture may be working against the product.
This is particularly important for agentic products because their entire value proposition is often based on increasing the amount of work software can perform autonomously. Pricing should encourage customers to delegate more valuable work to the product, not make them afraid to use it.
A practical framework for pricing an agentic B2B product
Before deciding on a number, an agentic company should answer a sequence of questions.
First, what job is the agent actually being hired to perform? Describe it in business language rather than technical language. "Resolve customer issues" is more useful than "execute LLM workflows."
Second, what is the smallest measurable unit of completed value? It could be a resolution, processed document, qualified account, completed reconciliation, investigated alert or another clearly identifiable piece of work.
Third, what does that work cost the customer today? Consider employee time, outsourcing costs, errors, delays and opportunity cost. This establishes the economic context for pricing.
Fourth, how reliably can the outcome be attributed to the agent? The closer pricing gets to revenue or another downstream business result, the more important attribution becomes.
Fifth, what drives the vendor's own cost? Model inference, external APIs, data providers and compute still matter. Value should determine the pricing architecture, but unit economics still determine whether the business works.
Sixth, can the customer predict their bill? Give buyers enough visibility, commitments, limits or capacity options to budget confidently.
Finally, does the model improve as the agent gets better? If better automation, cheaper inference and improved orchestration increase both customer value and vendor margins, the pricing architecture has room to compound.
The agentic era changes what software companies are selling
Traditional SaaS largely monetized access to capability. Agentic software increasingly monetizes the execution of work.
That distinction may ultimately matter more than whether the pricing page says "usage," "credits," "outcomes" or "capacity."
At BeyondB, we think the starting point for agentic pricing should therefore be the economics of the job being performed. Understand what the agent does, what that work is worth, how reliably the value can be measured and how much of that value the product can reasonably capture. Only then should the company decide whether the commercial unit is an action, workflow, outcome, capacity commitment or a combination of them.
The companies that get this right will not necessarily be the ones with the cleverest pricing structure. They will be the ones where customers can clearly see the relationship between what they pay and what the agent accomplishes for their business.
In the agentic era, that may become the simplest test of a good B2B pricing model.
