The SaaS seat worked because headcount was a reasonable proxy for how much software a company used, and one more user cost the vendor almost nothing. AI agents break both halves of that. An agent might live for 30 seconds or run continuously, and every run costs the vendor real money in inference, retrieval and tool calls, so charging per agent measures nothing useful. Vendors are already replacing the seat with actions, credits, conversations, resolutions and outcomes, and the workable answer is probably a hybrid: a platform fee, human seats for supervisors, committed consumption, overages, and outcome fees where results can actually be verified. The bigger shift comes next. Once agents can compare approved services at runtime, weighing execution cost against review cost and the cost of retries, vendors compete for each task rather than for the annual contract. The next unit of value may not be the user, or even the agent. It may be the job, successfully completed.
For most of the SaaS era, pricing software has been simple.
A vendor counts the people who need access, assigns each one a seat, and charges the customer every month or year. Different tiers unlock different features, but the basic unit stays the same: one human user.
AI agents break that unit.
An agent might exist for 30 seconds, call a few services, finish one task, and disappear. Another might run continuously across thousands of workflows. A company with 500 employees could end up running tens of thousands of short-lived agents, each doing a sliver of work on someone’s behalf.
Charging $20 a month per agent would be arbitrary. The number of agents doesn’t tell you much about how much software got consumed, what it cost to provide, or what value it created.
If agents become the primary users of software, the seat probably isn’t replaced by another kind of seat. It’s replaced by a stack of prices: access to the platform, consumption of resources, payment for work that actually got done.
And that might only be the first change.
Once agents can compare services at runtime, vendors stop competing just for the annual contract. They start competing for every individual workload.
The assumption hidden inside the SaaS seat
Technically, SaaS never assumed the customer was a human. The customer is usually an organization. But SaaS pricing assumes software consumption and business value scale with the number of employees using the product.
That relationship is imperfect even today. One employee uses a product for hours every day, another logs in once a month. Seat pricing survives anyway because it’s simple, predictable, and easy to audit. Headcount is a decent proxy for organizational use, and the marginal cost of serving one more conventional user is low.
Agents challenge all three of those assumptions.
First, an agent isn’t necessarily a durable identity. It can be created for a workflow and terminated when the workflow ends. Counting agents is like pricing cloud computing by the number of containers created instead of the resources consumed.
Second, agent activity varies enormously. A lightweight agent that classifies one document is not economically equivalent to an agent that reasons through a complex case, searches several databases, and invokes a dozen external tools.
Third, AI has a real variable cost. Model inference, retrieval, orchestration, tool calls, all of it costs the vendor money every time it runs. Unlimited use behind a flat seat price can turn a successful, heavily used product into a bad business.
So the problem isn’t really whether an agent counts as a user. It’s that the seat no longer measures cost or value in any reliable way.
The new units of agentic software
Vendors are already experimenting with replacements. At least five different units of value are emerging in the market.
1. Actions
Salesforce Agentforce meters autonomous work through Flex Credits. A standard Agentforce action consumes 20 credits, voice actions consume more. The agent itself isn’t the billable unit. The work it performs is.
That’s more meaningful than charging for an agent identity, but it raises a new question: what counts as an action? A customer can wrap their head around a refund, an appointment booking, an account update. Every retrieval, classification, or intermediate step required to get there is a harder thing to put a price on.
2. Responses and computational consumption
Microsoft Copilot Studio uses Copilot Credits. Organizations buy tenant-wide capacity packs, and an agent burns through varying numbers of credits depending on the action or response it completes. Microsoft’s billing documentation is upfront that different agent capabilities carry different rates.
This looks like cloud pricing. Measurable, tied to the vendor’s actual costs. It also risks becoming hard for buyers to forecast. A simple-looking business process can chew through a variable number of model responses, grounding operations, and tool actions without anyone knowing the total until the invoice arrives.
3. Conversations
Salesforce also offers conversation-based pricing for customer-facing agents. A conversation is more intelligible to a business than a token or a model call. It maps to something the organization already measures.
But a conversation is still just an approximation of value. One answers a delivery-status question. Another retains a valuable customer or resolves a complicated service request. Charge the same for both and you’ve recreated the weaknesses of the seat, just at a smaller scale.
4. Resolutions
Customer service has become the clearest early market for outcome-based pricing, because the outcome can usually be defined.
Intercom Fin charges $0.99 per outcome. Intercom counts outcomes such as a successfully resolved issue or a completed procedure, and charges once per conversation even if Fin answers several questions along the way.
Zendesk AI Agents use automated resolutions as the billing unit. You pay when an issue is resolved without escalating to a human. Its newer automated-resolution tiers recognize that resolutions differ in complexity and value, too.
These models move pricing closer to the customer’s own economics. The customer isn’t paying because software was available, or because an agent made an attempt. The vendor gets paid when the system actually finishes the job.
5. Business outcomes
Sierra has made outcome-based pricing the center of its pitch. Its argument: AI agents let software vendors charge for specified results instead of access.
That idea stretches well past customer support. An invoice processed. A qualified sales opportunity created. A payment recovered. A claim adjudicated. An appointment booked. A contract reviewed.
This starts to make AI software look less like a tool and more like a service provider.
There probably will not be one replacement for the seat
Every model here solves one problem and creates another.
Token and compute pricing tracks the vendor’s costs closely, but customers don’t buy tokens for their own sake. They buy completed work.
Outcome pricing aligns payment with value, but only when the outcome is unambiguous and attributable. Did the customer stop replying because the agent solved the problem, or because the customer gave up? Did the AI sales agent create the opportunity, or just touch a prospect who was already going to buy?
Usage-based pricing produces volatile bills. Outcome-based pricing produces arguments over measurement. Flat subscriptions hide expensive consumption. Pure seat pricing leaves vendors underpaid when agents do far more work than the humans supervising them.
The likely answer is a hybrid:
- A platform or control-plane fee for administration, security, governance, integrations, and auditability.
- Human seats for the employees who configure, supervise, or collaborate with the agents.
- Committed consumption in the form of prepaid credits, actions, tasks, or capacity.
- Metered overages when activity runs past the commitment.
- Outcome fees where valuable results can be clearly defined and independently verified.
This gives vendors a way to recover variable costs and share in the value they create. It gives customers a predictable baseline with some real connection between spending more and getting more work done.
Bessemer Venture Partners’ AI pricing playbook frames this as a shift from charging for access to charging for work, and draws a line between copilots, agents, and AI-enabled services because each needs its own value metric. Stripe’s guide to AI SaaS pricing lands in a similar place: subscription, usage-based, outcome-based, and hybrid, not one universal replacement.
From annual procurement to decisions made at runtime
The bigger change might come after agent consumption becomes measurable.
Today, a business selects software through a human process. Procurement evaluates vendors, negotiates a contract, commits the organization for a year or more. Employees then use whatever got selected, whether or not it’s the best or cheapest tool for the task in front of them.
An agent could make a smaller version of that same decision every single time it works.
Given several approved services, it could pick a model, a database, a search provider, or a specialized API based on what the task actually needs. A low-risk classification goes to a fast, cheap model. A complex legal analysis goes to something more capable and more expensive. A time-sensitive workflow favours low latency. A confidential process might require Canadian data residency or a privately hosted model.
Price becomes an input into a routing decision, not a term you review once a year at renewal.
That doesn’t mean autonomous agents get corporate credit cards and go rogue. Enterprises will still set approved suppliers, negotiated rates, security controls, data-handling rules, spending limits. Procurement may actually matter more, because its decisions get encoded into machine-enforceable policy instead of a PDF nobody reads.
Within those boundaries, though, agents could allocate workloads dynamically.
The rational choice isn’t necessarily the cheapest price per call. An agent, or the routing system supervising it, has to weigh the full expected cost of getting the job done:
Expected task cost = execution cost + review cost + expected cost of failure and retries
A five-cent service that succeeds half the time can be more expensive than a twenty-cent service that reliably finishes the job. Accuracy, latency, security, availability, the cost of human review, all of it becomes part of the math.
That’s a different kind of software market. Vendors compete not just to become the organization’s system of record, but to win the next eligible task. Software pricing becomes machine-readable. Service quality becomes something you measure continuously. Work moves the moment the price-performance relationship shifts.
Software starts competing for workloads in something closer to an actual market.
The risks of pricing successful work
Outcome pricing sounds almost too clean: customers pay only when they get value. In practice it creates incentives that need real governance.
A vendor paid per resolved ticket has a reason to classify more interactions as resolved. A vendor paid per qualified lead has a reason to loosen what counts as qualified. A vendor paid per completed claim has a reason to optimize for speed over fairness or accuracy.
The definition of “success” becomes part of the product, and part of the contract. Buyers need:
- Clear, auditable outcome definitions
- Quality thresholds, not just completion counts
- Rules for reversals, errors, and reopened work
- Independent measurement, since the vendor’s system is also the judge
- Spending caps and anomaly detection
- Visibility into the steps, models, and external services used
- Human review for high-impact decisions
This matters even more when one agent pays another agent’s service. Without cost controls and traceability, a workflow can rack up chains of charges nobody can predict or explain after the fact.
FinOps practices built for cloud computing will likely spread into agent operations: forecasting consumption, attributing cost to business processes, comparing providers, optimizing for the cost of a successful outcome instead of just chasing fewer tokens.
The unit of value is becoming the job
The SaaS seat isn’t going away. It still works when a person is the primary user of an interface, and it still gives enterprises the budget predictability they want. Copilots, administrators, agent supervisors will keep having seats.
But the seat matters less wherever autonomous systems do a growing share of the work.
The shift is already visible. Salesforce charges for agent actions. Microsoft meters agent capabilities through credits. Intercom and Zendesk charge for outcomes and resolutions. Sierra built its entire commercial model around successful work.
The next phase is more disruptive. Once agents can evaluate approved services at runtime, vendors compete for each task on price, quality, latency, and risk. Annual contracts increasingly set the boundaries of the market instead of deciding every transaction inside it.
If agents become the primary users of software, the next pricing unit might not be the user. It might not even be the agent.
It might be the job, successfully completed.
Frequently Asked Questions
Why doesn’t per-seat pricing work for AI agents?
Because it quietly relies on three things that agents break. A seat assumes a durable identity, but an agent can be created for one workflow and terminated when it ends. A seat assumes roughly comparable use, but classifying a single document and reasoning through a complex case across a dozen tools are not the same product. And a seat assumes near-zero marginal cost, which stops being true once every run costs the vendor money in inference, retrieval and tool calls. Counting agents is like pricing cloud computing by how many containers you created.
What are vendors charging for instead?
Five units are emerging. Actions, as with Salesforce Agentforce, where a standard action consumes 20 Flex Credits. Responses and computational consumption, as with Microsoft Copilot Studio’s credits and tenant-wide capacity packs. Conversations, which businesses find easier to reason about than tokens. Resolutions, where Intercom Fin charges $0.99 per outcome and Zendesk bills for issues resolved without human escalation. And broader business outcomes, which is where Sierra has built its entire pitch.
Is outcome-based pricing the answer?
Only where the outcome is unambiguous and you can actually attribute it. Did the customer stop replying because the agent solved the problem, or because they gave up? Did the AI create the sales opportunity, or touch a prospect who was already going to buy? Outcome pricing also hands the vendor a reason to define success generously, since a vendor paid per resolved ticket benefits from calling more things resolved. It aligns payment with value when it works, and produces arguments over measurement when it doesn’t.
What should a buyer negotiate for?
Auditable definitions of what counts as a completed outcome, quality thresholds rather than raw completion counts, and explicit rules for reversals, errors and reopened work. Push for independent measurement, because otherwise the vendor’s system is also the judge. Then add the operational controls: spending caps, anomaly detection, visibility into which steps, models and third-party services a workflow actually used, and human review on high-impact decisions. This matters most when one agent is paying for another agent’s service, where chains of charges can pile up before anyone notices.
Does this mean agents will choose their own software?
Within boundaries, yes. Enterprises still set the approved suppliers, negotiated rates, security controls and spending limits, except those decisions get encoded as machine-enforceable policy rather than a PDF nobody reads. Inside that fence an agent can route each task on its merits, and the cheapest option isn’t automatically the rational one. The calculation is execution cost plus review cost plus the expected cost of failure and retries, which means a five-cent service that succeeds half the time can be more expensive than a twenty-cent service that reliably finishes the job.