AI agent pricing: seats, usage, outcomes, or hybrid?

AI agent pricing can charge for employee access, measured consumption, accepted outcomes, or a combination. Choose seats when individual access is the product, usage when consumption is visible and controllable, outcomes when both parties can verify completion, and hybrid pricing when access and variable activity deserve separate charges.

Before comparing prices, ask the vendor to explain one disputed run. What happened, which event created the charge, and what evidence would reverse it? That conversation reveals more than a headline price per task.

An agent can produce useful output without satisfying the buyer's acceptance rule. It can also consume billable resources while failing. A sound commercial agreement makes those cases legible before the first invoice.

Separate the billing unit from the package

The unit determines what gets counted. The package determines what the customer receives, including access, allowances, controls, support, and commitments. Keep those decisions separate in your SaaS pricing strategy.

Model	What creates the charge	Appropriate boundary	Question to resolve
Seats	A licensed person	Employee access to a defined product	Which actions and usage are included?
Usage	Tokens, actions, conversations, or another meter	Activity with an understandable consumption pattern	Can the buyer predict and limit the meter?
Outcomes	An event satisfying the contract's completion rule	A result both parties can verify	Who decides whether the result qualifies?
Hybrid	A fixed component plus a variable meter	Persistent access plus changing activity	What does the base include before overage begins?

A credit is a denomination, not a complete pricing model. You still need to know which activities consume credits and at which rates. A conversation, an action, and an accepted research report describe different boundaries. Comparing their prices as though each represented one equivalent task produces a misleading estimate.

Start with the value proposition: what result is the buyer purchasing? Then distinguish the promised value from the event the billing system can observe. The two may be related without being identical.

Read the rate card behind the credit

Public vendor terms checked on October 17, 2026, illustrate why scope matters. Salesforce lists Flex Credits at $500 per 100,000 credits and Conversations at $2 each. Its $5-per-user monthly Agentforce User License requires Flex Credits; the $125-per-user monthly employee add-on offers unmetered usage within its stated scope. These are different offers, not interchangeable all-in prices. Salesforce's pricing page details the distinctions.

The August 31 rate card lists 20 Flex Credits per Standard Action and 30 per Standard Voice Action in production. The corresponding sandbox multipliers are 16 and 24. Certain customers instead have Voice Minutes terms. The dated rate card is the source for these values.

Those numbers describe billing multipliers. They do not measure customer savings, compare equivalent business results, or predict how many actions your agent will need. An account-specific estimate also needs the action mix, environment, applicable licenses, and other billable services. Recheck the current card and order form before purchasing.

Write the outcome rule before the price

An outcome price needs a definition that survives an exception. Does completion mean a generated answer, a completed procedure, a customer's confirmation, or an independently verified result?

Intercom currently advertises Fin from $0.99 per outcome. Its definition includes customer-confirmed resolution, no further request for help after a response, or a completed Procedure, including handoffs. It charges once per conversation. The integrated offer combines seats and usage; the existing-helpdesk offer has no seat costs and carries a minimum commitment. Intercom's pricing terms make that distinction explicit.

A billed outcome therefore should not automatically be described as a customer-confirmed, fully autonomous resolution. Read the actual definition instead of substituting the result you hoped the word meant.

For an agent you are buying or packaging, document these rules:

• Acceptance: the observable event and evidence required for completion.
• Exceptions: what happens when inputs are missing, the customer disappears, or a human takes over.
• Repetition: whether reopening the same case or rerunning a task creates another charge.
• Timing: when acceptance becomes final and how later corrections are handled.
• Disputes: who can review the evidence and authorize a credit.

These are proposed contracting questions, not a description of every vendor's implementation. The useful boundary is the one your product can reliably detect and your customer can inspect.

Keep time to value separate from invoice timing. A system might bill when a report is delivered, while the buyer only receives value after a seller uses it to make a decision.

Match the model to the operating boundary

Consider a hypothetical account research agent. It receives a company domain, checks approved sources, and returns an evidence packet for a seller. A polished paragraph is not sufficient: the packet needs the correct company, dated claims, source links, and explicit unknowns.

Seat pricing could fit a seller-facing research assistant with a defined allowance. Usage could fit a backend process where volume varies and each retrieval is recorded. Outcome pricing could fit accepted evidence packets, provided acceptance does not depend on a seller's subjective reaction weeks later.

A hybrid might charge for the governed workspace and an allowance of research runs, then meter additional accepted packets. Explain what happens to unsuccessful runs. Do they consume the allowance, incur third-party charges only, or remain entirely the provider's responsibility? Each answer creates different incentives.

External data enrichment creates another boundary. A model may produce no usable report even though a licensed data request succeeded. Decide whether that expense is included, passed through, or excluded before calling the offer outcome-based.

Seats remain reasonable when named users receive recurring access and the contract contains autonomous consumption. Usage remains reasonable when the buyer can influence volume and investigate unexpected activity. Outcomes are strongest when completion is prompt, attributable to the agent's bounded task, and auditable.

Avoid charging a research agent for closed-won revenue simply because research can influence a sale. Product fit, seller execution, procurement, and timing also affect that result. A narrower accepted deliverable is easier to reconcile than an ambitious but disputed attribution claim.

Make a trace-based estimate

Build the estimate from representative task traces, not from the maximum volume promised in a demo. This guide does not report a production pricing test or measured savings.

For each candidate workflow, collect the input class, completed steps, billable units, retry count, terminal state, human review requirement, and downstream acceptance. Separate simple runs from missing-data cases and long or ambiguous requests.

Translate each observed event using the applicable rate card. Then construct low, expected, and high monthly scenarios using explicitly labeled volume assumptions. Keep the observed consumption per sampled run separate from the assumed number of future runs.

For a straightforward hybrid, the estimate consists of the base commitment, applicable overage, separately billed services, and contractual adjustments. Confirm whether the base fee includes units, represents a credit balance, or is charged in addition to every unit. Those three arrangements produce different bills.

Compare cost per accepted deliverable only after defining acceptance consistently. Retain unsuccessful runs in total spend even when the denominator includes only accepted deliverables. Otherwise, a system that retries repeatedly can appear artificially economical.

For an outcome contract, estimate the vendor-defined billable count and the buyer-accepted count separately. A handoff may qualify for one and not the other. Show the difference openly rather than silently selecting whichever denominator makes the product appear cheaper.

Treat internal review capacity as an operating constraint. A low unit price is not attractive if every packet requires a specialist to reconstruct its sources. Track review minutes separately; do not relabel a forecast of avoided minutes as measured labor savings.

Connect this evaluation to your go-to-market metrics, but keep product economics distinct from revenue attributed to sales execution. Implementation fees and ongoing managed services also belong on separate lines from the agent subscription.

Build the event trail before billing

The billing system should receive an event with enough context to reconstruct the charge. At minimum, retain a customer identifier, workflow and run identifiers, a stable event identifier, event time, unit quantity, terminal state, acceptance evidence reference, and the version of the relevant rule and price.

Separate an attempted action from an accepted billable event. Give technical retries a stable identity so duplicate delivery does not become duplicate billing. Preserve adjustments instead of silently editing the original record. A reviewer should be able to follow the chain from an invoice line back to the evidence that authorized it.

Stripe's current documentation recommends Metronome for new usage-based integrations. Its existing Billing Meters route sends meter events to Stripe for aggregation at the end of the billing period. Do not assume an older meter tutorial is the recommended starting point for a new product. Stripe's usage-recording guidance explains that distinction; its current usage-based billing overview describes Metronome's role.

Billing infrastructure cannot decide whether a research claim is correct. Your application needs to establish acceptance before emitting an outcome event. Assign an owner for disagreements between application state, usage records, and invoices, with a documented reconciliation process in RevOps.

Also distinguish an alert from a hard stop. Decide what happens when the spend threshold is reached, including whether in-flight tasks finish and whether failed calls can retry. A GTM engineer needs that stop behavior specified alongside the happy path.

Frequently asked questions

What is AI agent pricing?

It is the commercial model used to charge for an agent's access, consumption, or defined results. The useful specification includes the unit, rate, allowances, commitments, exception rules, and evidence behind each charge, not just a monthly number.

Are credits the same as tokens?

No. Tokens measure model input or output. Credits are vendor-defined billing units that may cover actions, prompts, or other services at different multipliers. Read the conversion rules and applicable usage types before estimating a credit balance's capacity.

Is outcome pricing always cheaper?

No. The rate and definition determine the bill. An outcome contract can reduce exposure to some failures, but minimum commitments, handoff rules, separate services, and acceptance differences still matter. Compare equivalent accepted deliverables using the full relevant spend.

Can seat and usage pricing coexist?

Yes. A hybrid can price employee access separately from autonomous activity. Check what is included in the seat or base fee, which events consume additional units, and whether the same activity is counted by more than one meter.

What should a pricing pilot measure?

Record billable units, accepted deliverables, failures, retries, review effort, and exception reasons for a bounded sample. Label the sample size and input mix. Use its traces to inform scenarios, not to claim a universal cost or guaranteed savings.

Before signing or shipping a pricing plan, choose one successful run, one failed run, and one ambiguous run. Ask both the buyer and the provider to explain the charge for each. Resolve disagreement at that level before committing to volume.

For more practical AI pricing guidance, join the newsletter below.