AI agent services, business models and pricing

On this page

Chapter 15 of The Hitchhiker's Guide to the Agentic Economy

Report hub · Previous: enterprise commercial relationships · In this chapter: unit of sale · business models · job example · economics card · Next: Part IV, applications, firms and institutions

Our view

An agent service can charge for seats, calls, tokens, time, transactions, subscriptions or outcomes. None of those meters automatically describes the value the customer receives.

For this guide, the useful comparison unit is a defined unit of accepted work: a briefing that met its scope, an invoice that was matched, a booking that was confirmed or a record that was corrected. Providers may bill another meter. A durable business must still connect that meter to delivery cost, human review, failures, rework, support, remedy and repeat demand.

Key Takeaways

• Pricing models reveal which result the provider promises and where it places the acceptance boundary.
• The unit of sale, the billing meter and the customer's unit of value can be three different things.
• Usage pricing transfers volume variability. It does not allocate outcome, retry, quality or support risk by itself.
• Managed services and consulting remain useful where judgement, change and exceptions cannot yet be expressed as a stable product interface.
• Durable service economics depend on contribution and repeat accepted work; invocation, settlement and gross revenue counts describe intermediate activity.

This chapter compares public pricing structures, marketplace and billing documentation, procurement material and service terms checked on 13 September 2026. These sources show available commercial models and operating primitives. They do not establish current demand, average price, retention or profitability. No service was purchased and no Agentic Economy cost or repeat-use cohort exists for this chapter.

Sources and scope

Agentic Economy reviewed official product, billing, marketplace and government sources. Public prices and terms are dated supply, not market benchmarks. Provider examples are not independent customer evidence. The synthetic AE-JOB-001 numbers are labelled as illustrative and are not quotations or a business case. About Agentic Economy explains the publication. Corrections can be submitted through the contact page.

The market is testing several ways to sell agent services

Agent services are being sold as seats, subscriptions, usage, transactions, marketplace plans, managed services, consulting engagements and outcome-linked offers. The models overlap because providers are still learning which part of the work customers value and which costs remain variable.

Infrastructure providers usually meter technical consumption such as tokens, calls, compute or workflow runs. Application companies increasingly package access to an agent or a recurring workflow. Marketplaces add distribution and transaction fees. Managed-service and consulting providers retain human judgement around delivery and exceptions. A smaller group is experimenting with pricing tied to completed or accepted outcomes.

Our view is that the category will not converge on one pricing model. Technical infrastructure will remain usage-based, while customer-facing services move closer to completed work. Hybrid models will be common because agent delivery still combines software consumption, human review and commercial responsibility.

Separate the unit of sale, meter and unit of value

In this guide, unit of sale is the item described in the offer or contract. Billing meter is the quantity used to calculate the charge. Unit of value is the result the customer uses to decide whether the service was worthwhile. Accepted work means a delivered unit that the named reviewer or rule has judged complete against the promised result.

For a competitor-briefing service:

• the unit of sale might be one briefing, a monthly research service or access to a workspace;
• the billing meter might be a fixed project fee, analyst hours, source calls, generated tokens or a monthly subscription; and
• the unit of value might be one timely briefing that covers the required competitors, cites approved sources and passes analyst review.

Those quantities are linked, not collapsed. If the service makes three model calls and delivers one accepted briefing, the customer did not receive three briefings. If retries raise token use, a usage invoice can increase while customer value stays flat. If a monthly subscription includes unused capacity, low meter volume does not automatically imply churn; the buyer may be paying for readiness, support or reserved capacity. The offer states which is true.

Two ledgers, one job

An agent service needs two linked views:

1. Operational meter: model, data, tool, compute and workflow events, including retries and failures.
2. Commercial job: promised result, delivery, acceptance, invoice, correction, refund and repeat decision.

The operational meter explains cost and system behaviour. The commercial job explains what the customer bought and whether it was accepted. A billing system can aggregate the first. It cannot infer the second unless the buyer explicitly purchases the metered event itself.

For example, Australia's Peppol eInvoicing framework carries standardised business documents between participating accounting systems. It does not decide whether an agent had authority to order or whether the buyer accepted the work (Australian Taxation Office, eInvoicing).

Stripe documents meter events with a customer, event name, numeric value, timestamp, identifier and optional dimensions, then aggregates them asynchronously for billing. Metronome separates products, rate cards and contracts. Chargebee documents recurring, one-time, usage, prepaid, included-usage, minimum-commitment and tiered structures. These products provide rich billing state. They do not define the acceptance test for a briefing, booking, code change or other customer job (Stripe usage-based billing; Metronome, how it works; Chargebee included-usage models).

Eight business models allocate risk differently

Model	What is sold or billed	Who carries the main variance	Good fit	Evidence needed before calling it durable
SaaS or seat	Access for a period or entitled user/role	Buyer carries unused capacity; supplier carries baseline platform and support cost	Stable workflow, administration and collaboration	Active entitlement, accepted use, support cost, renewal and exit evidence
Usage or pay-as-you-go	Requests, events, tokens, compute, records or other meter	Buyer carries volume and retry variance; supplier carries unit-cost drift unless repriced	Variable or modular machine consumption	Meter integrity, caps, duplicate control, unit cost, accepted output and credits
Transaction or per order	Completed order, transfer, booking or other event	Supplier/platform may carry payment, fraud, refund and chargeback risk depending on configuration	Commerce with a discrete event and recoverable fee base	Exact completion event, merchant of record, tax, refund, failure and payout record
Subscription or commitment	Recurring access, credits, reserved capacity or minimum spend	Buyer carries unused commitment; supplier carries reserved capacity and service continuity	Predictable repeat demand	Multi-period accepted use, overage, credit expiry, margin, notice and renewal decision
Marketplace	Distribution plus checkout, billing or fulfilment components	Responsibility depends on platform terms and charge configuration	Buyers prefer an existing procurement or discovery channel	Seller identity, fee, MoR, fulfilment, support, tax, refund, dispute and portability
Managed service	A continuing business function or service level	Supplier carries staffing, review and exception management; buyer retains outcome definition	Complex or consequential work needing operating cover	Capacity, review, service levels, accepted jobs, incidents, remedies and transition
Consulting or project	Expertise, time, milestone or defined deliverable	T&M places scope variance on buyer; fixed scope shifts more to supplier	Discovery, implementation, change and one-off judgement	Scope, change control, milestone acceptance, rework, IP, warranty and handover
Outcome-linked	Agreed result or improvement, often with a base fee	Supplier carries more performance risk; both carry attribution dispute	Measurable, controllable and valuable result	Baseline, attribution, measurement authority, timing, cap, exceptions and remedy

Hybrid model is a deliberate combination of two or more structures, such as a platform fee plus usage, a retainer plus accepted-job fees, or a base fee plus an outcome bonus. Hybrids often fit because support and readiness have fixed costs while execution varies. They also make invoices harder to explain. The contract needs precedence rules and a single reconciliation path.

SaaS and usage are not opposites

A service can sell account access and meter selected work. The subscription pays for entitlement, administration, storage, support or reserved capability; usage pays for variable execution. The practical questions are whether the buyer can predict spend and whether the seller can predict contribution.

For an agent service, meter design needs extra care around retries and composition. A job can call the same tool twice after a timeout, use three upstream models or discard an output during review. If the buyer is charged every internal attempt, the supplier transfers its reliability cost outward. That may be legitimate when the buyer explicitly purchases raw compute or API events. It is harder to defend when the offer promises a completed result.

Usage pricing therefore needs:

• a stable event definition and version;
• idempotency and duplicate rules;
• treatment of failed, retried, cached, partial and test traffic;
• a ceiling, alert and hard-stop policy;
• visibility before the bill closes;
• credits or refunds when the event did not produce the promised service; and
• a way to reconcile meter events to customer jobs.

Marketplace is a distribution model, not a responsibility model

A marketplace can provide discovery, procurement access, contract surfaces, billing and payouts. It can also leave fulfilment, metering, invoicing, tax, support and collection with the publisher.

Microsoft's current transactable SaaS guidance says publishers remain responsible for fulfilment, metering, billing, invoicing, payment and collection even when Microsoft facilitates parts of the transaction. AWS Marketplace private offers can carry negotiated pricing and terms for supported SaaS and professional-service product types. Stripe Connect changes who creates charges, collects fees, bears negative balances and handles disputes according to configuration; its tax documentation separately allocates tax responsibilities by marketplace configuration. The word “marketplace” does not settle those responsibilities (Microsoft, plan a SaaS offer; AWS Marketplace private offers; AWS supported private-offer product types; Stripe Connect marketplaces; Stripe Tax with Connect).

The direct and channel versions of an offer remain separate records. Fees, tax, support, refund ownership, customer identity and data portability can differ. Distribution is valuable only if the resulting accepted-job contribution justifies the channel cost and dependency.

Managed service and consulting are not transitional embarrassments

Agent systems can operate across changing models, fragile integrations, ambiguous tasks and exception-heavy business processes. A managed service can sell accountable operating cover: a named team, review, escalation, correction and continuity. Consulting can help define the job, redesign the workflow, integrate systems and transfer capability.

Those models are appropriate when the buyer cannot yet specify a stable interface or safely own the failure path. The human work must still be measured. Hidden review and rework can make a fixed fee unprofitable. A retainer can hide low accepted demand. Time-and-materials can reward effort instead of outcome. Milestone and fixed-scope models need clear acceptance and change control.

A productised service may emerge when repeated jobs reveal a stable input, output, acceptance and exception pattern. Treat that as a hypothesis until a named cohort shows repeat accepted jobs, bounded exceptions and contribution after review and support. It is not a command to replace people.

Outcome pricing is an evidence contract

Outcome pricing sounds closest to customer value. It is also the easiest model to state vaguely.

AWS's current prescriptive guidance describes outcome-based pricing as payment tied to measurable results and notes the need for agreed success criteria and measurement. That is provider guidance, not evidence of market adoption or realised economics (AWS, outcome-based pricing for agentic AI).

An outcome-linked offer needs:

• a baseline and observation window;
• an exact outcome definition and data source;
• control or adjustment for other causes;
• a measurement owner and audit access;
• a payment cap and timing rule;
• treatment of partial success, delay and negative effects;
• customer and supplier obligations;
• a dispute and fallback price; and
• a remedy if the claimed outcome later reverses.

Outcome pricing works where the provider can materially influence and measure the result. A research service can own delivery and acceptance of a briefing. It cannot credibly promise that the buyer's revenue will rise without controlling the buyer's decisions, market conditions and sales execution.

What can be packaged for agents

The agentic economy contains more than standalone agents. A supplier can package:

Offer	What the buyer receives	Required commercial boundary
API or data product	Versioned response, record or dataset	Schema, provenance, freshness, limits, price, licence, uptime and remedy
MCP tool or server	Discoverable tool interface and invocation route	Tool identity, input/output, authority, data, side effects, support and change policy
Agent skill	Instructions that help an agent select or operate a capability	Source, version, compatible tool/service and safe-use limits; the skill is not proof the service works
Workflow or agent	Multi-step execution toward a bounded result	Objective, dependencies, authority, retries, evidence, acceptance and handoff
Human-plus-agent service	Accountable deliverable with software-assisted production	Named supplier, review, service level, correction, liability and continuity
Marketplace or gateway	Discovery and routing across suppliers	Attribution, seller identity, pass-through price, fee, support, refund and provider failure

The packaging decision exposes what the supplier owns. A PAY.md, Agent Card, OpenAPI document or marketplace listing can make a capability easier to find and call. It does not create a legal entity, accurate result, current price, service level or remedy. A paid endpoint can settle a transaction and still return an unacceptable output. A managed provider can absorb those gaps, but its contract and price must account for them.

AE-JOB-001 under four commercial models

AE-JOB-001 is the guide's synthetic competitor briefing. The illustrative offer is one sourced briefing covering five named competitors and up to ten approved public sources, one-business-day delivery after a complete brief, analyst review, a bounded external research allowance, and correction or refund under stated conditions. No amount is supplied: price, cost and contribution remain live evidence fields rather than invented market inputs.

A practical first-offer ladder

Suppliers tend to begin at the layer they can reliably own. Accepted repeat work determines whether they expand into more of the outcome.

Offer	Buyer-facing promise	Price structure to test	Move up, remain or stop
Reviewed one-off briefing	One defined briefing, source and coverage limits, delivery date, named acceptance test, one correction and stated refund condition	Fixed accepted-job fee with a hard external-cost cap	Move to recurring only after the first job is accepted and reconciled; re-scope or stop if the acceptance test cannot be made stable
Managed recurring briefing	A cadence of reviewed briefings plus intake, support, correction and continuity	Base fee for readiness/support plus included accepted jobs and a stated overage	Remain managed while judgement and exceptions are material; reprice when review/support exceeds the planned capacity
Self-serve component or API	A versioned data, extraction or generation unit with explicit limits and errors	Usage or prepaid units, with duplicate, failed-call and credit rules	Productise only when repeated jobs show stable input/output, low exception variance and a buyer able to own final acceptance

Outcome-linked pricing is a later hybrid, not the default first offer. Add it only when the supplier can influence the result, both parties can establish a baseline and measurement owner, and the fallback fee and dispute path are acceptable.

1. Per-call technical service

The buyer pays for search, extraction or generation calls. The supplier exposes a schema and meter. The buyer assembles the final briefing and owns acceptance.

This model fits a technical buyer that wants components. It needs per-event price, retries, rate limits, data rights, output schema and service credits or refunds. The buyer must count orchestration, review, discarded results and support. The upstream call can succeed while the briefing fails.

2. Subscription workspace

The buyer pays for monthly access, seats or included usage. Staff and agents can research and produce briefings inside the entitlement.

This model buys capacity and workflow rather than one result. Active users, accepted briefings, overage, support and unused capacity reveal whether that capacity creates value. Logins and token consumption alone do not establish a renewal case.

3. Managed recurring briefing service

The supplier delivers a defined number or cadence of reviewed briefings, handles the agent stack and exceptions, and commits to service and correction terms. Price can combine a base retainer with an accepted-job or overage component.

The supplier now carries more integration, model, tool, review and continuity risk. It needs capacity planning, clear intake and change rules, acceptance, rework limits, support cover and an orderly handover if the relationship ends.

4. Consulting or outcome-linked hybrid

The supplier first helps the buyer define the research workflow, sources, governance and integration. Later fees can follow milestones, accepted deliverables or an agreed operational outcome that the supplier can influence.

This model suits an uncertain early scope. It needs baseline, milestone acceptance, change control, IP and data terms, knowledge transfer and a fallback when the outcome cannot be attributed. A vague promise to “improve decisions” is not a measurable outcome.

Facts needed before choosing

Fact	Why it changes the model
Job frequency and seasonality	Determines whether account commitment or spot purchase is efficient
Stable input/output and acceptance	Determines whether the work can be productised or needs managed judgement
Model, data, tool and infrastructure cost	Determines exposure under fixed or usage pricing
Review minutes and rejection rate	Reveals the human delivery cost hidden by automation
Retry, timeout and rework rate	Shows whether technical activity inflates cost or customer charge
Support and exception volume	Determines base fee and operating cover
Customer acquisition and onboarding effort	Shows whether small transactions can repay commercial cost
Refund, credit and remedy frequency	Converts gross billings into retained revenue
Accepted repeat rate and expansion	Distinguishes novelty from durable demand

The Service Economics Card

The Service Economics Card is an Agentic Economy editorial proposal. It is a linked view of the Commercial Job Record. It is not a statutory accounting statement, revenue-recognition policy or claim that one billing system calculates every field.

Field	Record	Why it matters
Service and version	Supplier, buyer, offer/contract, service version and period	Keeps price and operating claims tied to a current offer
Unit of work	Bounded job/result, included scope, dependencies and retry rule	Defines what the buyer expects
Acceptance	Test, reviewer, deadline, accept/reject/waive and correction/refund rule	Separates delivery from customer value
Price basis	Fixed, seat, usage, transaction, subscription, marketplace, managed, consulting, outcome or hybrid	Explains the invoice meter and risk allocation
Revenue event	Charge/invoice and credits, refunds or disputes linked to the job	Converts gross activity into retained commercial value
Delivery path	Agent steps, models, data, tools, people, region and support	Shows what performs the work and creates cost
Variable cost	Model/API, data/tool, compute, review, support, retries, rework, marketplace/payment and integration allocation	Makes contribution testable
Failure and rework	Attempts, timeouts, rejected output, correction and escalation	Prevents reliability cost from disappearing
Contribution view	Accepted-unit charge less measured job-linked costs	Supports a management decision, not statutory reporting
Cash and reconciliation	Invoice, due date, settlement, payout, tax, fees, adjustment and exception	Shows when money and ledger agree
Demand and repeat	New, accepted, reordered, expanded, paused or exited relationship	Tests whether the job has durable demand
Unknowns	Unmeasured cost, acceptance, liability, freshness or dependency	Unknown is not zero

The direct contribution bridge

direct accepted-unit contribution view
  = contracted charge for accepted work
  - credits, refunds and disputes
  - variable model, data, tool and infrastructure cost
  - human review, support and exception handling
  - retries, rework and failed-delivery cost
  - marketplace and payment fees
  - allocated implementation and integration maintenance

This is a partial management view for comparing jobs, not gross margin, operating profit, accounting or tax advice. It excludes costs unless the organisation deliberately allocates them. A fully loaded view must state the cohort and period, then add customer acquisition and onboarding, fixed product and management cost, general overhead, working-capital or financing effects, tax treatment and any capitalised investment under the organisation's policy. Never compare two services unless their allocation rules and denominators match.

Decision worksheet — no invented benchmark

The contribution bridge has two relevant states: the expected case and a failure-heavy case. Measured values and labelled assumptions keep the distinction visible. The report does not prefill currency amounts or percentages because even a prominently caveated number can be misquoted as Agentic Economy pricing or a market margin.

Field for one accepted job and a named period	Expected case	Failure-heavy case
Contracted charge	P_expected	P_failure
Credit, refund or variable consideration	R_expected	R_failure
Model, data, tool and infrastructure cost	T_expected	T_failure
Human review, correction and support	H_expected	H_failure
Payment, channel and job-linked integration allocation	C_expected	C_failure
Direct accepted-job contribution	P_expected - R_expected - T_expected - H_expected - C_expected	P_failure - R_failure - T_failure - H_failure - C_failure
Costs still unallocated	Name acquisition, fixed team/product, overhead, working capital, tax and capital items	Name the same omissions; do not compare scenarios with different boundaries

The decision is whether the measured failure case still fits the offer's stated floor and capacity—not whether a model invocation was cheap. A real operator names the cohort and period, replaces assumptions as jobs close, and preserves the rejected or refunded denominator.

The accessible bridge

Stage	Count or value	Do not infer
Billable activity	Metered calls, tokens, seats, time or transactions	Delivered work or revenue quality
Delivered work	Results made available under the offer	Customer acceptance
Accepted work	Results passing the stated acceptance test	Positive contribution
Retained charge	Invoice/charge less credits, refunds and disputes	Cash collection or margin
Contribution view	Retained charge less job-linked delivery and commercial costs	Company profit or statutory margin
Repeated demand	Later accepted job or renewed relationship	Durable retention without a cohort and period

One measurable job trace

The first useful implementation is an event contract, not a synthetic profit figure. For AE-JOB-001, retain this sequence under one job ID:

offer_v1 accepted -> authority_v1 approved -> execution_attempt_1
execution_attempt_1 -> metered upstream events and measured delivery cost
delivery_v1 -> reviewer decision: accepted | rework | rejected
accepted -> invoice line or entitlement consumption
rework/rejected -> correction, credit or refund under the offer
retained charge -> job-linked costs -> contribution view
later accepted job -> repeat evidence for the named buyer and period

The acceptance event names the criterion version, reviewer or deterministic rule, timestamp and reason. Billing consumes that event only when the contract makes accepted work the charge boundary; a raw-usage product can bill its defined meter while still reporting delivered and accepted customer work separately. Retries, cache hits, test calls, partial results and discarded outputs carry explicit billability rules. Cost allocation states what is directly measured, estimated or allocated, so an unmeasured review minute does not become zero.

Four commercial outcomes

No universal call-count threshold separates experimentation from repeat demand. The useful unit is a named cohort over a defined review period:

• Productised: the same input, output and acceptance contract survives repeat customers; exceptions fit the designed path; direct and fully loaded economics clear the organisation's stated floor; and the buyer can own the final use.
• Managed: judgement, source selection, change handling or accountability remains material and customers pay for that operating cover.
• Repriced or narrowed: accepted-job contribution is positive only in the optimistic case, review/support exceeds planned capacity, or remedies repeatedly consume the fee.
• Stopped: the service cannot meet its acceptance or safety boundary, fully loaded contribution remains below the stated floor after a defined test period, or repeat accepted demand does not appear in the named cohort.

The commercial owner sets the floor and test period. No universal percentage or ten-job rule fits every capital, risk and service context.

When high activity destroys value

A service can show rising calls and falling economics when:

• unreliable dependencies create billable or unbillable retries;
• human reviewers correct most outputs;
• a low transaction price cannot repay customer acquisition and support;
• usage spikes create provider costs before the seller can reprice;
• customers receive credits or refunds after failed delivery;
• marketplace, payment and tax costs were excluded from the offer;
• one customer dominates demand or abuses a generous meter;
• integration changes require recurring non-billable work; or
• customers do not repeat after the first experiment.

A higher unit price is only one response. Suppliers also narrow the result, improve acceptance, cache or batch upstream work, move ambiguity into a managed tier, create committed capacity, add minimums, change the meter or withdraw from jobs they cannot deliver reliably. The Service Economics Card makes those economic responses visible.

What the market has not resolved

Public pricing still reveals more about the supplier's meter than the customer's unit of value. Tokens, calls, runs and seats are easy to count. Accepted work, avoided labour, correction cost and commercial responsibility are harder to standardise across customers.

We expect infrastructure pricing to remain consumption-based and application pricing to become more outcome-shaped. Managed services will persist where judgement and exceptions remain material. Marketplaces will influence packaging by standardising listings, plans and billing, but the underlying service economics will remain provider-specific.

What the sources establish

Current documentation establishes broad supply of SaaS, usage, transaction, subscription, commitment, marketplace, managed-service, consulting, outcome-linked and hybrid structures. Billing platforms can meter, rate, credit and invoice complex usage. Marketplaces can carry offers and negotiated terms. Procurement systems can qualify suppliers and reconcile purchase orders, receipts and invoices. Provider guidance describes outcome pricing and managed service patterns.

It does not establish:

• which model has the largest or fastest-growing agent-service demand;
• an average price, take rate, gross margin or accepted-job cost;
• that a public price is what enterprise buyers pay;
• that usage events produced accepted work;
• that an outcome was caused by the supplier;
• that a marketplace owns fulfilment, tax, support or disputes in every configuration; or
• that Agentic Economy's illustrative briefing is profitable or repeatable.

Unresolved market questions

Five developments would materially change our view of agent-service economics:

• buyers renew agent services on raw calls or tokens without any output, acceptance, remedy or job-cost signal;
• independent cohorts show one pure pricing model producing durable accepted demand across APIs, managed services and enterprise workflows without hybrid support or risk terms;
• reliable cross-provider data links price meter, delivery, acceptance, review, failure, remedy, contribution and repeat demand;
• outcome fees are routinely accepted and reconciled without a baseline, attribution method, measurement owner or dispute path; or
• an agent marketplace configuration consistently makes the platform the seller, merchant of record, tax owner, fulfiller and remedy owner across participating offers.

The largest evidence gaps remain practical:

• no independent enterprise record follows an agent service from supplier onboarding through accepted repeat work and exit;
• public provider examples rarely disclose review minutes, rejection, rework, refund, support and integration-maintenance cost;
• comparable outcome-pricing cohorts are not public;
• public marketplace listings show supply, not buyer demand or contribution; and
• Agentic Economy has not yet run the synthetic briefing job, billed it, measured cost or observed repeat demand.

Conclusion

An agent service becomes a business when it packages a result a buyer can understand, deliver and accept, then survives the real cost of doing that repeatedly.

Technical meters allocate variable cost, control spend and make billing possible. They are not the whole commercial truth. The market will increasingly link the meter to accepted work, including retries, review, failures, support, credits and integration cost. Managed services and consulting will persist where the work remains too ambiguous to productise; outcome pricing will remain bounded by measurement and attribution.

No standard model is emerging. Infrastructure remains consumption-priced, applications are moving closer to completed work, and managed delivery carries the ambiguity between them. The winners will make the job, acceptance, meter, remedy and contribution legible as one commercial system.

About the author and editorial record

Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking, pricing advice, accounting advice or a claim that any listed service model has been independently benchmarked by Agentic Economy.