AI Agent Pricing: What Should Count as a Billable Outcome?

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 rules and linked guidance were rechecked on October 21, 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, identified in Stripe's October 1, 2026 post as Metronome's CEO and founder, 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, such as gains in revenue or pipeline and a reduction in customer 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 identifies a measurement problem: agreeing on the result, detecting it, and separating your product's contribution from other causes.

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:

1. 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.
2. Unit boundary: what starts and ends one unit, such as a conversation, a ticket, or a job.
3. 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."
4. Observation window: how long you wait before an event becomes billable.
5. Uniqueness: one identifier per unit, so a duplicate report bills once.
6. Exclusions: the cases that never bill, written as a list.
7. Reversal and dispute policy: what cancels a billed unit, until when, and how the credit appears.
8. Inspection: which records behind each charge the buyer can see.
9. 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: false

occurred_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.

An example lifecycle: attempts, evidence, an observation window, then billing, with exclusion and reversal as the two exits.

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 charges once for a conversation even when Fin performs several 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; default escalations are not charged.
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, including after the billing period changes.
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, a support-only unit no longer described all the work customers bought, 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. For accounts on Zendesk's resolution-allowance model, "Don't allow overage" pauses capabilities that require paid resolutions at the allowance limit. The setting cannot be changed for Forethought AI agents by Zendesk plans. Under the default, "Allow overage," agents keep serving customers and overage is billed monthly.

The cited cap and alert pages do not specify a complete billing rule for work already in progress at the limit. 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, invites an argument about which part came from the software and which from the sales team. 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.

A procurement-minded commenter, u/highfivesalute, described the budgeting objection on October 15, 2026: "Procurement answer: boring old predictable pricing." The commenter preferred an annual amount finance could plan around. This is one practitioner report, not evidence of what all buyers prefer.

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

1. Choose one task type with recent volume.
2. Write its billable-event definition, the predicate sentence and the nine answers, and map it to the record fields.
3. Pull recent task traces you already have access to under your current agreements.
4. 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.
5. 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.
6. Publish the definition on your pricing page and in a help article, and update both whenever definition_version changes.

If many traces land in the unclassifiable row, fix the definition before you choose the model and the price.

FAQ

How do you verify an AI outcome?

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.

Is outcome-based pricing better than token-based pricing for AI agents?

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.

Who gets credit when a human finishes the conversation?

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.

What's the hardest part of implementing outcome-based pricing?

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.

Does outcome-based pricing always work better than usage-based or per-seat pricing?

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.