How AI Agents Buy From Your Business

An agent does not arrive at your homepage, compare three pricing plans, create an account, copy an API key, and remember to renew next month. It arrives with an objective. It looks for a resource that can help, calls the resource, and needs a machine-readable way to understand the price and prove that spending is authorized.

That compresses a familiar commercial journey into a request-response loop. The interface changes, but the seller’s responsibilities do not disappear. Someone still has to define what is being sold, express the price or pricing rule, decide which payment methods are acceptable, verify the buyer’s commitment, deliver the result, calculate the final charge, record the transaction, and make the proceeds usable.

The useful mental model is a seven-step flow:

Seller-side transaction flow

BuyerSeller

1. 01Discover
2. 02Request
3. 03Quote
4. 04Commit
5. 05Execute
6. 06Charge
7. 07Settle

1. Discover

Before an agent can buy, it has to find something worth requesting. Discovery may happen through a search engine, an agent directory, an API description, a link from another service, or a protocol-specific discovery mechanism.

For the seller, this means a paid resource needs more than a technically reachable URL. Its purpose, inputs, outputs, constraints, and commercial terms have to be understandable without a sales conversation. A vague endpoint is difficult for a developer to integrate and even harder for an agent to evaluate.

Discovery is not the payment protocol’s job. It is a distribution and product-description problem. Good technical documentation, crawlable public pages, accurate metadata, and stable resource identifiers all make the resource easier to evaluate.

Some protocols add a more specific discovery path. The x402 Bazaar is a machine-readable catalog of payable HTTP endpoints and MCP tools exposed by supporting facilitators. The Universal Commerce Protocol takes a profile-based approach: a business publishes its services, capabilities, and payment handlers at /.well-known/ucp. These mechanisms can make an offering legible to compatible agents, but they complement rather than replace clear public documentation and broader distribution.

2. Request

The agent makes an ordinary request for the protected resource. If access requires payment, the seller responds with a machine-readable payment requirement instead of the result.

In x402, the familiar HTTP 402 Payment Required status becomes the negotiation point. The response describes what payment is required. The agent can select a supported option, prepare proof, and retry. AWS documents the same basic pattern for protected web resources: request, payment-required response, payment proof, verification, and access.

This matters because payment becomes part of the resource interaction. The agent does not need to leave the request, navigate a checkout page, and return with a session that a human created.

3. Quote

The payment requirement is effectively a quote. It should answer the questions a buyer needs before making a commercial commitment:

• What resource or action is being bought?
• What is the fixed price, or how will the final price be calculated?
• In which currency or asset will the buyer pay?
• Which network or payment method is accepted?
• How long is the quote valid?
• What conditions determine whether the seller will execute?

Some products have a fixed price. Others depend on work performed or output produced, so the exact amount is not known until after execution. In that case, the quote needs a machine-readable pricing rule and a maximum the buyer can authorize. The x402 up-to scheme, for example, lets a buyer authorize a maximum while settlement uses the actual amount determined from resource consumption.

That is a commercial policy decision. A protocol can carry a fixed amount, cap, or pricing rule, but it cannot decide what your product should cost.

A quote also needs to be stable enough to audit. If its price or terms can change silently while an agent is authorizing payment, disputes become hard to resolve. Treat the quoted resource, fixed amount or cap, pricing rule, expiry, and relevant terms as one versioned commercial statement.

4. Commit

The agent now needs permission to spend and a way to turn that permission into a commitment the seller can verify. Google’s Agent Payments Protocol describes the first part as an accountability problem: when an agent acts for a person or organization, the ecosystem needs evidence of what the user intended and what was authorized.

Authorization is not always a click at the moment of purchase. A person might approve an exact transaction, or delegate bounded authority in advance: a maximum amount, an approved merchant, a category, a time window, or a recurring task. The resulting commitment may cover an exact amount, an amount up to a cap, or a claim that will be settled with others later.

The agent retries the request with that commitment attached. The seller, or a facilitator acting for the seller, verifies it against the quote before doing paid work. Verification establishes a reliable economic basis to proceed; it does not necessarily mean that the final amount has already been calculated or that funds have already settled.

The seller does not need to design the buyer’s delegation system. It does need to keep the buyer’s mandate, the verified commitment, and the eventual fulfillment record connected so the transaction can be explained later.

5. Execute

Only after the commitment has been verified should the seller perform the paid action or return the protected result. This is the essential commercial boundary: do not confuse “the agent sent something that resembles payment” with “the seller has a verified basis to fulfill.” It does not require every payment rail to settle before execution.

Execution should be idempotent where practical. Agents retry requests, networks time out, and payment confirmation can arrive at an awkward boundary. A stable request or transaction identifier helps the seller avoid executing twice—or charging twice—for one intended action.

When price depends on output, execution also needs to meter the quantity that determines the charge. Record that usage against the same request and commitment instead of deriving it later from unrelated logs.

6. Charge

For a fixed-price resource, the charge is the amount quoted and committed. For an output-priced resource, the seller calculates the actual amount after execution from the agreed rule and measured usage. That amount must remain within the buyer’s authorized cap.

The response should make success legible to the agent. Return the purchased result, a clear status, and enough commercial information to reconcile the action: the request or commitment identifier, measured usage where relevant, the final charge, and the settlement state. A successful response may include a completed settlement result, but it may instead identify a valid claim that will settle later.

7. Settle

Settlement turns the accepted charge into funds the seller can recognize and use. It may happen in the same request-response cycle, shortly afterward, or in a batch. Depending on the payment method and operating model, it can involve network confirmation, currency conversion, treasury decisions, payout, accounting records, tax treatment, and reconciliation.

In x402 batch settlement, a facilitator validates and stores a cryptographic commitment for each request, the seller serves the resource, and value is transferred later through a batch or network-specific settlement mechanism. The buyer still makes a bounded commitment before execution; batching changes when value moves, not whether the seller verifies a claim first.

This financial batching is separate from an API accepting several actions in one request. A product can batch work, batch settlement, do both, or do neither. Keep an identifier and amount for every billable action even when multiple charges ultimately move together.

This is the point where “accept a payment” and “operate a payments product” visibly diverge. A protocol can standardize the exchange. A platform or internal operating system still has to coordinate what happens around it.

For a seller, the commercial record should connect the priced resource, the buyer’s request, the verified commitment, measured usage, the final charge, the delivered result, and settlement. Without that chain, support and finance teams are forced to reconstruct a machine-speed transaction from separate logs.

How this differs from human checkout

Human checkout is designed for a person who can interpret a page, fill in missing context, accept terms visually, pass an interactive challenge, and wait through redirects. Its state often lives in a browser session.

An agent purchase needs explicit state. Product identity, price, accepted methods, authorization, and result must be carried in data that software can interpret. The agent needs to know whether to proceed, ask its user, choose another payment option, retry, or stop.

This does not make the flow less governed. It makes good governance more machine-readable.

How this differs from API keys

An API key answers “who is making this request?” and may link usage to a monthly invoice or prepaid balance. It usually requires onboarding before the first useful call: create an account, obtain a credential, store it, and agree to a billing relationship.

Per-request payment answers a different question: “does this request satisfy the seller’s commercial requirement?” That can enable a buyer to pay for one resource without first establishing an ongoing account.

The two models can coexist. An established customer may prefer an API key and consolidated billing. A new agent may prefer to discover and purchase a single result. The seller should choose based on the product, risk, and relationship—not because one mechanism must replace every other one.

Seller-readiness checklist

Before exposing a resource to agent buyers, make sure you can answer:

• Is the resource described clearly enough for software to evaluate?
• Does each request map to a stable product or billable action?
• Is the price fixed, or can the buyer authorize a clear maximum and metering rule?
• Are accepted payment methods and expiry rules explicit?
• Can a valid economic commitment be verified before the paid action executes?
• Are retries safe, with idempotency and transaction identifiers?
• Can support trace quote, request, commitment, usage, charge, result, and settlement together?
• Are refund, dispute, tax, fraud, and payout policies owned somewhere?
• Can an agent distinguish a retryable failure from a final refusal?
• Does a human remain in control of material purchasing authority?

If several answers are “not yet,” the missing work is probably not another checkout screen. It is the commercial and operational layer around the request.

Protocol plus operations

Agentic commerce works when two layers meet. Protocols make the purchase exchange interoperable: how a seller requests a commitment, how a buyer supplies it, and how both sides understand the result. Platform operations turn that exchange into a dependable business process: pricing, accepted methods, verification, metering, charging, settlement coordination, records, and payout policy.

recuut is being built around that seller-side operating layer. If you are deciding which resource an agent should be able to buy first, start with one request that has a clear outcome, a price you can explain, and a fulfillment step you can safely repeat.