MENU
AI customer support agents perform measurable work: conversations handled, questions answered, tickets resolved, and workflows completed. That makes them a natural fit for pricing models tied to the work itself. Per-conversation pricing charges for each defined interaction, while per-resolution pricing charges when the agent reaches an agreed outcome rather than simply consuming compute.
The next step is making that commercial model agent-ready. Instead of requiring a human to complete checkout before every interaction, builders can expose the support agent as an autonomously purchasable service. Agentic payment infrastructure can connect pricing rules, access controls, metering, and settlement so authorized systems can purchase the service programmatically.
The pricing model matters, but it is only one part of monetization.
A support agent also needs a commercial interface.
The buyer, whether a human customer, platform, or another AI agent, needs to know what the agent does, what one unit of service costs, what triggers payment, and how access is granted after authorization.
That is what makes an agent autonomously purchasable.
The implementation can be broken into five stages.
1. Define the billable event
Decide what customers are actually buying.
For customer support, the two clearest options are often:
Other units can work, including sessions, tool calls, credits, or combinations of those measures.
The important part is precision. A billable event should be observable and consistently measurable.
2. Register the agent and pricing plan
The agent becomes a commercial service once its endpoint is associated with a pricing and access plan.
A plan might represent conversation access, prepaid credits, time-based access, or another supported payment model.
3. Protect the service endpoint
The payment requirement needs to sit directly in front of the service being sold.
The API or agent endpoint should verify that the buyer has the required access before executing the protected operation.
Clear boundary. Authorized request in, paid service out.
4. Meter the conversation or outcome
Payment needs to correspond to actual work.
For conversation pricing, the system records the beginning and end of the defined session.
For resolution pricing, it records the event that satisfies the resolution criteria.
That event becomes the link between agent activity and revenue.
5. Verify and settle
The buyer satisfies the payment requirement, the service verifies authorization, the agent performs the work, and the relevant charge or credit consumption is settled.
The support agent remains the product. The payment layer makes access purchasable programmatically.
Per-resolution pricing moves the commercial unit away from seats, messages, or compute.
The customer pays when the support agent produces an agreed result.
That makes the definition of "resolved" the central design decision.
Bessemer Venture Partners' AI pricing playbook identifies resolved support tickets as an example of outcome-based AI pricing and cites $0.99 per resolved ticket as one market example.
That figure is better treated as an example than as a universal benchmark. Support products differ in complexity, cost structure, industry, and what counts as a successful resolution.
A vague definition creates disputes.
"Agent resolved ticket" is not enough.
Builders need an observable condition such as:
Different support environments need different criteria.
A password-reset agent can use a relatively objective completion event. Technical troubleshooting may require more nuanced rules.
The pricing model should follow the reliability of the measurement.
Outcome pricing works best when the agent reports the event directly.
That may involve:
Outcome-based pricing depends on defining the outcome before attaching billing to it.
The billing system should not have to guess whether value was delivered.
The product should expose the event.
Outcome pricing creates an additional question: what happens when the customer disagrees with the resolution?
That policy belongs in the commercial design.
Builders may define:
Clear rules matter more than aggressive billing.
If customers cannot understand why an event was charged, outcome pricing becomes harder to trust.
Per-conversation pricing shifts the billable unit from outcome to interaction.
That makes implementation simpler because the charge does not depend on proving that the agent solved the customer's problem.
The challenge moves elsewhere: defining a conversation.
A conversation needs a clear start and end.
Common signals include:
Without session boundaries, one long conversation might be counted as several interactions, or multiple unrelated requests might be treated as one.
The commercial definition should match the product experience.
Per-conversation pricing is easier to meter than per-resolution pricing.
It also means customers may be charged for conversations that ultimately escalate or fail to resolve the issue.
That does not make the model inherently weaker. It means the unit being sold is different.
The customer is buying access to an interaction rather than paying only for a successful outcome.
For early deployments, that simplicity can be useful because resolution measurement may still be evolving.
Not every conversation costs the same amount to serve.
A simple order-status question may require one retrieval. A technical-support interaction may trigger several tool calls, external API requests, or longer model usage.
Dynamic pricing or usage components can account for that variation when it materially affects cost.
The key is restraint.
Pricing should become more complex only when the underlying economics justify it.
Per-conversation and per-resolution pricing do not need to be mutually exclusive.
A support product might charge a platform fee plus conversations, include a bundle of support interactions, or use conversation pricing for basic support and outcome pricing for specific automated workflows.
Bessemer describes hybrid pricing as a way to combine predictable base revenue with usage- or outcome-linked expansion.
That structure can be useful when the AI agent has real marginal costs but customers still want predictable budgets.
Credits are especially useful when activity happens frequently or in small increments.
A customer can purchase a balance once and then consume prepaid credits as conversations, resolutions, or other billable events occur.
Funding and consumption become separate events.
That can be useful when the support agent handles many relatively small transactions that would be inefficient to settle individually through a conventional card payment.
Credits also create a natural budget boundary.
When the balance runs low, the system can request additional funding rather than allowing unbounded consumption.
An autonomously purchasable support agent cannot rely entirely on a human pricing page.
Software needs to understand that payment is required and how to satisfy it.
x402 provides one way to put that requirement directly into the HTTP interaction.
A buyer requests the protected resource. The endpoint indicates that payment is required. The buyer supplies the relevant authorization and retries the request.
The sequence is compact:
Request → payment requirement → authorization → service
For an AI support agent, the service might be one conversation, one resolved ticket, or access to a bundle of interactions.
The underlying payment mechanism can vary. The important part is that the commercial requirement can be interpreted and satisfied programmatically.
Making a support agent autonomously purchasable also means another agent may become the buyer.
That raises a separate problem: purchasing authority.
An AI agent should not need unrestricted payment credentials simply to purchase another service.
Card delegation provides one pattern: the buyer receives scoped payment capability rather than the underlying card credentials.
Controls can include:
The principle is simple.
Delegate authority, not credentials.
That allows an authorized buyer agent to purchase support capabilities while remaining inside financial boundaries defined by the user or organization funding it.
Pricing defines what should be charged.
Metering establishes what actually happened.
For a customer support agent, the metering layer may need to record:
The exact fields depend on the pricing model.
The objective stays the same: connect the billable event to a traceable commercial record.
Conversation pricing usually relies on session-state events.
The system records when the session starts, associates messages and tool activity with the session, and recognizes the event that closes it.
That session can then consume the appropriate credit or generate the relevant charge.
Outcome pricing requires an additional state transition.
The system needs evidence that the agreed outcome occurred before settlement.
That can be tied to a ticket event, application webhook, workflow result, or another defined signal.
The event needs to be deterministic enough to support reconciliation later.
A customer-support product does not need to be rebuilt from scratch to become agent-ready.
The support logic can remain unchanged.
The commercial layer sits around it.
Existing Express, FastAPI, and other service endpoints can be protected through agent integration patterns that verify payment or access before forwarding the request to the underlying application.
That separation matters.
Support teams can continue improving resolution quality, retrieval, escalation logic, and response generation without embedding payment logic throughout the application.
Customer support agents increasingly operate through more than one interface.
One service may expose an HTTP API. Another may offer MCP tools. A broader agent system may communicate through A2A-oriented workflows.
The commercial model should follow the service rather than being tied to one orchestration environment.
An MCP integration, for example, can expose a paid capability through a tool-oriented interface while the underlying pricing and access logic remains separate.
This matters when a support capability becomes reusable outside its original application.
A returns agent, account-management agent, or technical-support tool can become a service other agents invoke, provided access and payment travel with it.
Autonomous purchasing increases the importance of explicit controls.
The agent may be allowed to transact without a person actively approving each interaction. That makes limits, revocation, auditability, and credential handling part of payment design.
Relevant security controls include scoped permissions, tokenized payment handling, revocation, transaction records, and documented compliance measures.
For builders, those controls do not replace application-level security.
Customer authentication, support-data permissions, privacy controls, and agent authorization still need to be designed separately.
Payment authorization answers whether the service can be purchased.
Application authorization determines what the buyer can access after purchase.
Nevermined can provide the commercial layer around an existing customer support agent.
Its payment infrastructure supports agent services priced around measurable units such as calls, sessions, credits, or outcomes. That maps naturally to customer-support models such as per-conversation and per-resolution pricing.
The support agent still handles the customer interaction. The builder still decides what counts as a conversation or resolution.
Nevermined connects those definitions to payment plans, access controls, metering, and settlement.
A practical implementation can follow this sequence:
The x402 Facilitator can handle payment verification and settlement for supported flows, while payment plans define how access is priced.
Nevermined also documents a 5-minute setup for basic integrations using its SDKs.
The value of the model is architectural rather than promotional: the underlying support capability stays independent, while the commercial layer makes it possible for authorized software to purchase that capability programmatically.
Expose the agent through a protected service endpoint, define the unit being sold, associate that service with a payment plan, and publish payment requirements that software can satisfy programmatically. The underlying support agent does not need to change. The commercial layer determines whether the buyer is authorized, meters the relevant conversation or outcome, and settles the resulting transaction.
Per-conversation pricing charges for a defined interaction regardless of whether the customer issue is ultimately resolved. Per-resolution pricing charges only after a predefined outcome occurs. Conversation pricing is generally easier to meter, while resolution pricing creates closer alignment between payment and customer outcome but requires more precise rules for determining and disputing resolution.
Use an observable event rather than a subjective description. Depending on the support workflow, that could be a closed-ticket state, confirmed workflow completion, lack of escalation, customer confirmation, or another measurable signal. The definition should also cover reopened tickets, partial resolutions, and disputes before billing is attached to the event.
Yes, when the buyer has appropriate purchasing authority and the seller exposes machine-readable payment requirements. Agent-oriented payment flows can allow the buyer to satisfy the requirement programmatically rather than opening a human checkout for every transaction. Spending limits and scoped authority can constrain what the buyer agent is permitted to purchase.
Nevermined can provide the transaction layer around an existing support-agent endpoint by connecting payment authorization, pricing rules, metering, credits, and settlement. Builders define the commercial event, such as a conversation or successful resolution, while the payment layer verifies access and records the corresponding transaction. This allows the support capability to operate as an agent-ready service without embedding a separate checkout flow into every interaction.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
