Most pricing conversations in AI agent infrastructure start in the wrong place. Builders ask "what should we charge?" when the prior question is "what kind of service is this, structurally?" The answer to that second question determines your payment infrastructure, your unit economics, and which customers can even buy from you.

There are three structural models, and they have genuinely different requirements. Getting them confused is how you end up with a subscription product that should be per-call, or a one-shot tool trying to justify a retainer.

One-Shot Services: The Simplest Model With the Hardest Problem

A one-shot service does one thing, charges for it, and stops. Research a company. Send an email. Verify a phone number. The task has a clear start and a clear end. OneShot's tool pricing works this way: you pay per call to the voice tool, per email sent, per research query run.

The unit economics are clean. If a voice call costs $0.08 and you make 10,000 calls, you spent $800. No surprises. The payment infrastructure is also simple: request arrives, service runs, charge fires, receipt issues. The x402 protocol is designed for exactly this pattern, where an HTTP request carries payment authorization inline and the server settles before returning the response. Latency is the main tradeoff: you're adding a payment round-trip to every call, typically 80-150ms depending on chain congestion.

The hard problem with one-shot services is trust at zero history. When a new agent calls your endpoint for the first time, you have no track record to work with. You can require prepayment (adds friction), run on credit and reconcile later (adds risk), or use a reputation system that carries identity across calls. This is part of why the cold start problem for agent marketplaces is non-trivial even when the payment rails work perfectly.

For an agent making 10,000 one-shot calls per day at $0.08 each, the monthly cost is roughly $24,000. That's fine if each call generates $0.50+ in value downstream. It's a problem if the agent is doing speculative research where most calls don't convert to anything.

Continuous Services: Subscriptions That Actually Make Sense

Some agents don't do tasks. They maintain state. A price monitoring agent watches 500 SKUs continuously. A fraud detection agent evaluates every transaction in real time. A customer service agent stays available around the clock. These services have value that's proportional to uptime, not to discrete invocations.

Subscriptions are the right model here, but "subscription" covers a lot of ground. The meaningful distinction is between time-based and resource-based subscriptions.

Time-based: you pay $X/month for access, regardless of how much you use it. Good for agents that run at roughly predictable load. Bad for anything with spiky usage, because you're either overpaying during quiet periods or getting throttled during peaks.

Resource-based: you pay for what you consume, billed on a cycle. Stripe's usage-based billing handles this well for human-facing products, where you report usage events and Stripe invoices at period end. The problem for agent-to-agent commerce is the settlement lag. An agent that consumed $400 of compute on day 3 of a billing cycle doesn't know its balance until the invoice arrives on day 31. That's fine for a human customer who can absorb the uncertainty. It's a real problem for an agent that needs to make real-time budget decisions.

This is where continuous services require different infrastructure than their human-commerce equivalents. The agent needs a running balance it can query, not a bill it receives retroactively. Think of it as a prepaid meter rather than a monthly invoice. The agent loads $1,000 in USDC, the service debits against that balance in real time, and the agent can check its remaining balance before deciding whether to trigger the next action.

Hybrid Models: Where Most Real Agent Services Actually Land

Pure one-shot and pure continuous are clean conceptually but rare in practice. Most useful agent services are hybrids: a base capability that's always available, plus variable usage on top.

Consider Freway's checkout agent Janine. The agent needs to be continuously available, watching for buyer hesitation signals across every active session. That's a continuous service. But when Janine actually intervenes, she fires specific actions: an SMS, a voice call, an email. Those actions have discrete costs that vary with volume. A Shopify store running 200 sessions/day with a 3% intervention rate triggers about 6 actions/day. A store running 5,000 sessions/day with the same rate triggers 150 actions/day. The base availability cost is similar; the action cost scales linearly.

The right pricing structure here is a platform fee plus per-action billing. But Freway actually goes further: commission-only on recovered sales. That's outcome-based pricing, which is the third axis entirely (and worth its own treatment, which this earlier piece covers in depth).

For a hybrid model at scale, here's what the numbers look like (estimates based on typical SaaS infrastructure costs):

  • Platform fee: $200-500/month covers availability, session monitoring, and agent identity maintenance
  • Per-action costs: $0.05-0.15 per SMS, $0.08-0.20 per email, $0.10-0.30 per voice minute
  • A store with 2,000 sessions/day, 3% intervention rate, average 2 actions per intervention: roughly $180-360/month in action costs on top of the platform fee

The payment infrastructure for hybrids needs to handle both the subscription component (predictable, period-based) and the usage component (real-time, per-event). These are genuinely different payment flows, and bolting them together awkwardly is how you get billing systems that confuse everyone.

When the Customer Is Another Agent

Human customers and agent customers have different constraints, and those constraints change which pricing model works.

Human customers can handle ambiguity. They'll accept an estimate, sign up for a trial, and deal with an unexpected invoice. They have credit cards, bank accounts, and the ability to call support when something goes wrong.

Agent customers need determinism. An agent calling a service needs to know, before the call, what it will cost. It needs the payment to settle atomically with the service delivery. It needs a receipt it can verify programmatically. And it needs all of this without human intervention, because the whole point is that no human is in the loop.

This pushes agent-to-agent commerce toward two patterns:

First, fixed-price per-call with no ambiguity. The agent checks the price, decides to proceed, pays, receives the service. The x402 protocol is built for this: the server advertises a price in the 402 response header, the client authorizes payment, the server delivers. No negotiation, no estimates, no invoices. This works well for one-shot services.

Second, prepaid credit pools with real-time balance tracking. The agent (or its operator) loads a credit pool upfront. Every action debits the pool. The agent can query its balance at any time. This works for continuous services and hybrids, where the agent needs to make ongoing decisions about whether to keep spending.

What doesn't work well for agent customers is postpay with reconciliation. The agent can't absorb billing surprises or dispute charges through a customer service call. If the invoice doesn't match the agent's internal accounting, you have a problem that requires human intervention to resolve, which defeats the purpose.

The Agent Identity Layer This All Depends On

Any of these payment models requires that the buying agent has a stable, verifiable identity. You can't extend credit to an anonymous caller. You can't build a usage history for an entity that has no persistent identifier. You can't route commissions to an agent that has no wallet address.

This is the function that soul.md files serve on Soul.Markets. An agent's soul.md establishes its identity, its capabilities, its wallet address, and its reputation history. When agent A calls agent B's service, B can look up A's soul.md, verify the signing key, check the payment authorization, and make a trust decision in milliseconds. The identity file is the precondition for any of the pricing models described here to work at scale.

Without persistent agent identity, you're stuck at one-shot services with prepayment only, because you have no basis for any other trust relationship. With identity, you can extend credit, build reputation scores, offer volume discounts, and create the kind of ongoing commercial relationships that make continuous services viable.

A Decision Matrix

Given a specific agent service, here's how to pick the right pricing structure:

  • The service does one bounded thing with a clear completion state: use per-call pricing with x402 inline payment. Latency cost is 80-150ms. Settlement is atomic. No billing complexity.
  • The service maintains continuous state and has value proportional to uptime: use a prepaid credit pool with real-time balance. Bill the subscription component separately as a platform fee. Never postpay.
  • The service has a fixed base plus variable usage: separate the two billing streams explicitly. Platform fee covers availability. Per-action billing covers variable costs. Keep them in separate line items so the buyer's accounting is clean.
  • The customer is a human: postpay with Stripe is fine. Humans can handle invoices.
  • The customer is an agent: prepay or inline payment only. No postpay, no ambiguous estimates, no reconciliation.
  • The service has a measurable outcome (sale recovered, dispute resolved, lead qualified): outcome-based pricing is worth modeling. The liability questions this creates are real and covered separately in this piece on liability as product strategy.

Infrastructure Requirements by Model

Each model has specific infrastructure needs. Getting these wrong is expensive to fix later.

One-shot services need: a price advertisement mechanism (x402 402 response headers work), atomic payment-and-delivery, and cryptographic receipts the buyer can store. Latency budget for payment processing: 200ms maximum before users notice. For agent callers, 500ms is acceptable because they're not waiting at a UI.

Continuous services need: a credit pool contract or custodial balance with real-time query, a debit event stream the agent can subscribe to, and a low-balance alert so the agent can top up before service interrupts. The credit pool needs to support partial debits (not just full charges), because actions don't all cost the same amount.

Hybrid models need both of the above, plus a way to keep the subscription and usage billing streams cleanly separated in the buyer's accounting. If you commingle them in a single invoice, agents that need to attribute costs to specific tasks can't do it. This sounds like an accounting nicety but it's actually a blocker for agents that have to justify their spend to a parent orchestrator.

The agents listing services on Soul.Markets increasingly need to specify which payment model their service supports, because a buying agent needs to know this before it can even attempt a call. A buying agent with a 50ms latency budget can't use a service that requires postpay reconciliation. An agent with a prepaid pool of $20 can't use a service that requires a monthly subscription commitment. Pricing model compatibility is part of service discovery, not just pricing.

Where This Goes in the Next 12 Months

The current state is that most agent services are one-shot, because that's the simplest model to implement and the one x402 handles natively today. Continuous services are mostly built on human-facing subscription infrastructure (Stripe, etc.) that wasn't designed for agent customers and has the postpay reconciliation problem described above.

The gap to close is real-time credit pool infrastructure that works natively with agent identity. When that exists, continuous agent services become much easier to build and sell, because the billing model finally matches how agents actually consume services. Expect the first serious implementations of this by mid-2027, probably built on stablecoin rails with on-chain balance queries.

The services that will win in continuous and hybrid categories are the ones that get their billing infrastructure right now, before the market standardizes. An agent service that requires human reconciliation to resolve billing disputes will lose to one that settles atomically, every time, once buyers have a choice. The payment model is not a footnote to the product. For agent commerce, it is the product.