AI Agent Pricing: What Should Count as a Billable Outcome?
Before you choose seats, usage, or outcome pricing for an AI agent, write down the event you will bill. A decision table, a billable-event record, seven edge cases, and a modeled cost per outcome.
- Written by
- Puneet Arora (opens in a new tab)
- Published on
- Read time
- 16 min
Your agent retries a failed tool call, gets halfway through a workflow, hands the conversation to a person, and pays for inference at every step. Your customer looks at the same conversation and judges success by its own standard. When the invoice says "outcome" and nobody wrote down what that means, you get unpredictable invoices, disputes, and a margin you cannot forecast.
Write one auditable billable-event definition before you pick a rate. Choose an outcome unit only when completion can be observed, attributed, explained, and disputed under an agreed definition, at an operating cost you can accept. When it cannot, price an output your system observes, or a base fee with an allowance, and give the buyer spend controls.
The definition questions, record fields, and edge-case rules below are a proposed design. They are not a recognized standard, and they are not any vendor's policy or legal terms. Vendor pages were read on October 15, 2026.
TL;DR
- Separate four layers: input cost, performed action, delivered output, and business outcome. Bill on a layer both sides can inspect.
- Define the unit before the rate: success predicate, boundary, evidence, window, uniqueness, exclusions, reversal, inspection rights, and who settles disagreements.
- Cost per attempt says little about cost per billable outcome. In the illustrative model below, $0.12 per attempt becomes about $2.89 per net billable outcome.
- Seats, metered usage, and hybrid plans remain sound choices. Zendesk draws its outcome units from an allowance, and Intercom sets a minimum commitment for standalone Fin.
- Before you set a price, replay recent task traces through the edge-case checklist.
Separate four layers before you pick a unit
Scott Woody, CEO and founder of Metronome, splits AI pricing into three metrics on Stripe's blog: inputs such as tokens, outputs that are objective and verifiable such as a generated image or a sent email, and outcomes, which "could mean the customer making more money, building more pipeline, or reducing churn." This post adds a fourth layer between input and output: the performed action.
| Layer | What it is | Support-agent example |
|---|---|---|
| Input cost | Tokens, compute, and tool calls, paid on every attempt | Model calls while drafting replies |
| Performed action | Something the agent did, as your logs record it | A ticket update, a task-complete flag |
| Delivered output | The result the customer asked for, checkable by both sides under a written rule | A conversation that meets the agreed resolution rule |
| Business outcome | The customer's own result, shaped by many causes | Lower churn, more pipeline |
An API call that succeeds, or a flag the agent sets on itself, shows that the agent acted. It does not show that the customer received value, so billing actions as outcomes is usage pricing with a misleading label. At the top layer, Woody names the opposite problem: "There's a telemetry gap around what counts as the outcome, whether it occurred, and whether your product caused it."
Compare the five units on the same criteria
The alternatives a buyer already knows are seats, metered usage, and credits with an allowance. Intercom and Zendesk keep their outcome units next to those models. Zendesk draws resolutions from an allowance, and Intercom's pricing page sets a minimum monthly commitment for standalone Fin. Salesforce sells its agent product as Flex Credits, a per-conversation price, and per-user add-ons and licenses.
| Unit | Observability | Attribution | Buyer predictability | Implementation and dispute cost | Supplier unit economics |
|---|---|---|---|---|---|
| Seats (status quo) | High: user count is known | Not needed | High | Low | Exposed when agent work per seat varies |
| Metered usage: tokens, calls, credits (status quo) | High: your own meters | Not needed | Low without caps | Medium: metering, deduplication, alerts | Tracks your cost closely |
| Actions or outputs | High when your system emits the event | Low risk | Medium | Medium: event definition, deduplication | On outputs, failed attempts are your cost; on actions, the buyer's |
| Outcomes | Depends on the evidence rule | High risk: people and other tools contribute | Medium to low | High: verification, reversals, disputes | Margin moves with the success rate |
| Hybrid: base fee plus allowance or credits | Inherits the inner unit | Inherits the inner unit | Higher: fixed base plus caps | Medium to high | Base fee covers fixed cost; overage covers variance |
The ratings are this post's assessment. They show a trade: the closer a unit sits to the customer's result, the better it tracks value and the more each charge costs to observe, attribute, and defend.
Where each unit wins
PricingOS offers a decision path that fits the table. It reserves outcome pricing for cases where success fits "one unambiguous sentence" and you can absorb the failures. When usage varies strongly across customers, it points to credits with a published conversion or usage with a spend cap. Seats remain the simplest sale when usage is stable and the agent is one feature among many. When buyers demand predictability and you need cost coverage, it recommends a hybrid of a base fee plus an allowance, with overage priced transparently.
Add one step to that path: when the customer's result is out of reach but your system emits a clear output, price the output. BillingPlatform's comparison draws the same line: its working examples share "a clean success signal that the AI system itself generates and the customer can verify."
Define the unit before the rate
PricingOS frames outcome pricing as defining, in writing, the single event that triggers a charge, in a way a customer will not dispute on an invoice. A billable-event definition that holds up answers nine questions:
- Success predicate: the one sentence that says the unit happened. Brocoders asks whether "done" fits in one sentence that a lawyer and an engineer would both sign off on.
- Unit boundary: what starts and ends one unit, such as a conversation, a ticket, or a job.
- Evidence source: the record that proves the predicate. Flexprice's glossary says each verification signal needs "a timestamp and an actor so the charge survives a dispute."
- Observation window: how long you wait before an event becomes billable.
- Uniqueness: one identifier per unit, so a duplicate report bills once.
- Exclusions: the cases that never bill, written as a list.
- Reversal and dispute policy: what cancels a billed unit, until when, and how the credit appears.
- Inspection: which records behind each charge the buyer can see.
- Resolution: who settles a disagreement, and by when.
A billable-event record you can adapt
The billable-event record stores those answers for each charge. The values below are invented placeholders and contain no customer data.
# Proposed billable-event record: an illustrative design, not a standard
event_id: evt_9a21_example # unique; reused if the same event is reported again
task_id: task_7f3c
account_id: acct_example # customer or account scope
outcome_type: ticket_resolved
definition_version: "2026-10-01" # definition wording this event was judged against
success_evidence:
method: customer_confirmation # or system_check, no_follow_up_in_window
ref: evidence/task_7f3c/final_turn
eligibility: eligible # eligible | excluded
exclusion_reason: null # for example greeting_only, default_escalation
occurred_at: "2026-10-14T09:12:05Z" # UTC
observed_at: "2026-10-14T11:12:05Z" # UTC, when the window closed
observation_window: PT2H # ISO 8601 duration
status: billable # pending | billable | excluded | reversed
reverses_event_id: null # on a reversal record, the event it cancels
credit_ref: null # link to the credit issued, if any
actor:
completed_by: agent # agent | human | agent_after_human
human_touched: falseoccurred_at and observed_at separate when the work happened from when it became billable. definition_version ties each charge to the definition wording in force, which matters when you add outcome types later. reverses_event_id makes a reversal its own record, so the original stays intact for audit.
(opens the full-size image in a new tab)Test the definition against seven edge cases
The example rules are this post's design choices. The last column describes a vendor's documented rule where one exists.
| Case | Example rule | Treatment | Documented vendor rule |
|---|---|---|---|
| Retries | All attempts share one task_id; retry cost stays with the supplier. | Part of the original unit | Intercom: "You're only charged for one outcome per conversation, even if Fin takes multiple actions." |
| Duplicate delivery | A second copy with the same event_id is dropped. | Non-billable | Stripe tells you to use idempotency keys so a meter event is not reported more than once because of latency or other issues. |
| Partial success | Nothing bills unless the definition includes a smaller outcome type for the finished step. | Non-billable, or a new unit of a smaller type | Intercom does not bill when a technical error or logic issue prevents a Procedure from finishing. |
| Human handoff | A handoff the buyer configured as the result bills; an escalation because the agent failed does not. Record the actor. | New unit if configured; otherwise non-billable | Intercom bills a handoff that a Procedure calls for; for default escalations, "You are not billed for these escalations." |
| Reopened task | A reopen inside the reversal window creates a reversal record, even after invoicing. | Pre-agreed credit | Intercom deducts a resolution when the customer returns to the same conversation for more help, "even across billing periods." |
| Delayed outcome | The event stays pending until the window closes; evidence after a final invoice goes on the next one as an adjustment. | Part of the original unit, billed late | Zendesk evaluates email 72 hours after the first email, messaging 2 hours after the first message (adjustable up to 72 hours), and voice at hangup. Stripe may accept an event after an invoice is finalized without changing that invoice or adding it to the next one. |
| Disputed outcome | If the evidence fails the success predicate, the named reviewer issues a credit within the agreed time. | Pre-agreed credit | Zendesk has an LLM evaluate the conversation text for a verified resolution. Its page gives no dispute rule. |
The Stripe late-event rule has a contract consequence. If your billing system can accept an event without changing either invoice, your billable-event definition needs its own rule for late evidence.
What vendor definitions teach
Intercom defines a resolution as counted when, after Fin's last answer, the customer either confirms the answer was satisfactory or "exits the conversation without requesting further assistance." Zendesk hands the judgment to an LLM. If you also use these definitions to judge support quality, see this comparison of vendor resolution definitions as quality metrics.
Definitions also change. Stripe's account says Intercom's Fin first charged for each support conversation it resolved. When Fin expanded into work such as lead qualification, that single metric "became an insufficient representation of customer value," so Fin added more billable outcomes. The definition_version field is there for that day.
Give the buyer a control surface
In the same Stripe post, James Brown names the buyer's side of usage-based billing: customers "need to understand what drives usage, anticipate spend, set spend limits, and connect usage to value." Design spending caps, alerts, cost and usage visibility, spend estimates, audit records, and a way to contest an event.
Know whether each control warns or stops. In Stripe Billing, usage alerts notify you when a customer crosses a meter threshold, or trigger an invoice at a billing threshold; the alerts page does not describe either one as stopping usage. Zendesk's "Don't allow overage" setting is an enforced stop that pauses AI agent functionality at the resolution allowance limit. Under the default, "Allow overage," agents keep serving customers and overage is billed monthly.
None of the vendor pages here says what happens to a task already in progress when a cap is reached. Pick one answer (finish and bill, finish and waive, or stop and exclude) and write it into the definition. Credit pools are another control: Stripe reports that Intercom's Fin lets customers commit to a pool of credits and draw it down across outcomes without forecasting each one.
Model cost per billable outcome
This model is illustrative: every input is an assumption chosen to show the method. The boundary is one task type for one month.
| Line | Input | Result |
|---|---|---|
| Tasks started | 1,000 (assumed) | 1,000 |
| Evidenced completions | 600 complete, 400 do not (assumed) | 600 |
| Attempts | Succeeded tasks average 1.3, failed tasks 2.5 (assumed) | 1,780 attempts |
| Inference and tool calls | $0.12 per attempt (assumed) | $213.60, of which $120.00 (about 56%) goes to tasks that never complete |
| Reversals after reopen | 60 completions (assumed) | 540 net billable outcomes |
| Supplier-side human assists | 150 at $2.50 (assumed) | $375.00 |
| Disputes | 30 at $15.00 (assumed) | $450.00 |
| Verification | $0.02 per task (assumed) | $20.00 |
| Fixed overhead | $500.00 (assumed) | $500.00 |
| Total cost | $1,558.60 | |
| Inference per net billable outcome | about $0.40 | |
| Total cost per net billable outcome | about $2.89 | |
| Inference share of total cost | about 14% |
At $0.12 per attempt, the model still costs about $2.89 per net billable outcome, and disputes alone cost more than all the inference. It sets no price and claims no margin. Replace each input with numbers from your own traces.
When you cannot observe the customer's business result
You may not be able to observe the customer's business result, or prove your agent caused it. You can still bill a system-observable event that both sides agree, in advance, to inspect.
Woody's sales-agent example shows why. Charging on the revenue an agent generates, he writes, means "I've immediately invited a dispute over the relative value of human labor versus automated labor." Intercom bills a resolution under a published rule, and revenue never enters it. Your job is to prove the evidence rule was met, under a rule the buyer saw before it signed.
The case for keeping it simple
Seats are easy to budget, and a long billable-event definition adds friction to every sales conversation. PricingOS still calls seats fine, and simplest to sell, when usage is stable and the agent is one feature among many.
Woody goes further, as one CEO's opinion: "For everyone else, outcome-based pricing is, for all intents and purposes, a myth." He ties the exceptions to monopoly-like power or a ticket price high enough to justify the cost of measuring outcomes.
One Reddit user in r/AIAgentsInAction described the trade: "per-seat is easy to budget, but feels strange when two employees can generate completely different amounts of agent work. usage seems fairer until one tool-heavy workflow or retry loop turns into a much bigger bill."
If agent work per seat is stable, seats may be the right unit, and you do not need a billable-event definition at all. Where you do write one, the buyer needs to see only the predicate sentence, the exclusions, and the way to contest a charge.
When outcome pricing is a poor fit
- Your system cannot observe the business result.
- Attribution is ambiguous because people and other tools contribute to the same result.
- The feedback loop is long, so the result appears weeks after the work and the invoice.
- Dispute cost is out of proportion to the value of each unit. In the model above, disputes cost $450.00 against $213.60 of inference.
In those cases, price a system-observed output, or a hybrid of a base fee plus an allowance or credits, with spend controls.
Publish the definition where buyers read it
A billable-event definition settles disputes only if the buyer can find the current version. Intercom's billing rule, for example, is a public help article. Put your success predicate, exclusions, and reversal window on the pricing page and in a help article, and change both in the same release that changes definition_version. A stale pricing page reopens every dispute the definition was meant to close, and AI assistants that answer "how does this product bill?" can draw on those same public pages.
Keeping those pages current is a documentation problem. EkLine's Docs Agent comments on pull requests when it detects documentation impact and can open a pull request with the documentation fix for your team to review.
Replay your traces before you set a price
- Choose one task type with recent volume.
- Write its billable-event definition, the predicate sentence and the nine answers, and map it to the record fields.
- Pull recent task traces you already have access to under your current agreements.
- Replay each trace through the edge-case table and count how many land in each row: clean billable, retry, duplicate, partial, handoff, reopened, delayed, disputed, and unclassifiable.
- Decide what must change before you bill on this unit: a missing evidence field, a window that is too short, an unwritten exclusion, or a unit that should be an output.
- Publish the definition on your pricing page and in a help article, and update both whenever
definition_versionchanges.
If many traces land in the unclassifiable row, fix the definition before you choose the model and the price.
FAQ
Check it against a written success predicate and a named evidence source inside an agreed observation window. Intercom counts a resolution when the customer confirms the answer or leaves without asking for more help. Zendesk has an LLM evaluate the conversation text. Record a timestamp, the actor, and an evidence link for each charge.
Neither wins in general. Token pricing tracks your cost and leaves the buyer carrying retries and failed attempts. Outcome pricing moves that risk to you and works only when the outcome can be observed, attributed, and disputed under an agreed definition.
Decide in the contract and record the actor on every event. Intercom documents one split: a handoff that a customer-configured Procedure calls for is billable, and default escalations are not billed.
Defining the event so it survives a dispute, then paying to run that definition. In this post's illustrative model, inference is about 14% of total cost, so model verification and disputes before you set a price.
No. PricingOS still calls seats fine, and simplest to sell, when usage is stable and the agent is one feature among many, and Metronome's Scott Woody argues outcome pricing works only in a very limited set of circumstances. Outcome units fit when completion is discrete and system-observable.
Sources
- Why I tried to kill token billing (and why we kept it), Scott Woody, Stripe blog
- The "alien" economics of AI monetization, Stripe blog
- AI Agent Pricing: Per Seat, Usage, Credits or Outcome?, PricingOS
- Fin AI Agent outcomes, Intercom Help
- Intercom pricing
- About automated resolution tiers, Zendesk
- Managing resolution allowances, Zendesk
- Agentforce Pricing, Salesforce
- Record usage for billing with the API, Stripe Docs
- Set up usage-based alerts, Stripe Docs
- Outcome-Based Pricing for AI, Flexprice Glossary
- Outcome-Based Pricing: Architecting for the Agent Era, Brocoders
- AI Pricing Models Compared, BillingPlatform
- For enterprise AI agents, what would you rather pay for: seats, usage, or completed work?, Reddit r/AIAgentsInAction
- Prevent documentation drift, EkLine docs
