A payment-capable AI agent is not yet a buyer.
Give an agent a wallet and three payable research APIs. It may be able to sign a transaction, but it still cannot answer the commercial questions: Do all three services sell the same result? Is the cheapest quote actually cheaper after usage limits and retry risk? May the agent negotiate a higher quantity for a lower unit price? Which revision did its owner approve? What happens if the seller takes payment but returns an unusable result?
Those questions define machine-to-machine procurement. The payment is one transition near the end. The control plane is a versioned buy contract that connects the buyer's requirement, seller's quote, delegated authority, payment terms, delivery standard, and remedy.
The practical rule is: agents may discover and discuss broadly, but they should purchase only from a narrow, machine-verifiable contract.
Procurement Is a State Machine, Not a Tool Call
A tool call asks a service to do something. Procurement decides whether the service should be hired, on which terms, with whose authority, and against which acceptance test.
A useful lifecycle keeps those decisions explicit:
Each transition should name the object that caused it. A catalog record moves a service into the candidate set. A compatibility check qualifies it. A quote revision wins the comparison. A principal's grant authorizes the purchase. A payment record confirms value movement. An acceptance record closes the commercial outcome.
This prevents dangerous shortcuts. PAYMENT_CONFIRMED cannot skip directly to RESULT_ACCEPTED. A seller may have been paid but not delivered. A tool may have completed but failed the buyer's freshness or quality condition. A result can pass a JSON schema while answering the wrong question.
Start With a Machine-Readable Need, Not a Search Query
“Find the best market-data service” is a useful search prompt but a poor procurement instruction. “Best” has no measurable boundary, and “market data” does not specify freshness, geography, output, quantity, or permitted cost.
Create a procurement intent before discovery. The following is illustrative rather than a protocol standard:
The intent performs three jobs. It gives discovery a precise target, gives comparison a common measurement basis, and gives negotiation a boundary. It does not grant payment authority. The owner or treasury still needs a separate policy or signed grant that says which agent may spend, with which sellers, on which networks, and under which approval threshold.
Keep requirements and preferences separate. Output schema, legal data-use restriction, deadline, and maximum spend may be hard constraints. Lower latency or a richer explanation may be preferences. If a scoring system treats a mandatory privacy condition as merely one weighted factor, a cheap seller can “win” by violating a requirement that should have disqualified it.
Discovery Finds Candidates; It Does Not Make Them Comparable
Current protocols expose different pieces of a candidate record.
x402 Bazaar can catalog payable HTTP endpoints and MCP tools through facilitator discovery resources. Listings may expose the resource, accepted payment requirements, input/output information, method or tool name, and service metadata. It is useful for open discovery, but its official documentation also describes it as early development. APIs and catalog behavior may change.
MCP tool definitions describe a tool's name, function, input schema, optional output schema, annotations, and structured result. This helps a buyer determine whether it can call and parse the tool. MCP also warns clients not to trust tool annotations merely because the server published them. A tool definition is not a current commercial quote.
A2A Agent Cards advertise agents, skills, interfaces, capabilities, and security information. A2A then supplies messages, task states, updates, and output artifacts for interaction. That makes it a useful coordination and delivery interface, but its core model does not provide a universal price, refund, or procurement contract.
ERC-8004 registration files can advertise services and endpoints, while its reputation and validation registries can add cross-organizational trust signals. Those signals help qualification. They do not prove that the listed price is current or that the service will satisfy this buyer's acceptance test.
The buyer should treat every discovery result as a lead. Before selection, resolve the current endpoint, verify identity and endpoint control where possible, fetch the live commercial terms, and timestamp the evidence. A stale listing should never override a fresh request-bound quote.
Normalize the Offer Before Ranking the Seller
Agents cannot compare $0.01 per call, $0.04 per accepted result, and up to $0.03 per task as if they were three prices for one unit. They describe different risk allocations.
Normalize each candidate into a buyer-defined comparison record:
Comparison field | Normalization rule |
|---|---|
Capability | Map seller description to the required capability and version |
Billable event | Call, token, task, result, outcome, time, or quantity |
Quantity | Convert the quote to the same expected workload |
Charge | Separate fixed amount, unit rate, authorization ceiling, and minimum |
Landed cost | Add expected network/conversion fees and bounded retry exposure |
Delivery | Express deadline, latency basis, output schema, and retrieval method |
Data rights | Normalize retention, training use, sharing, and deletion terms |
Remedy | Record retry, replacement, refund, credit, and dispute conditions |
Evidence | Mark each field as verified, seller-asserted, observed, or unknown |
Run hard filters first. Reject incompatible schemas, unavailable networks, disallowed data policies, unverified payment destinations, and quotes above the absolute budget. Then identify the Pareto shortlist: candidates that are not simultaneously worse on cost, delivery, evidence, and risk.
A weighted score may select among the shortlist, but it should not manufacture precision. Log the scoring version, weights, normalized inputs, and missing fields. Unknown reliability is not zero risk. Either reject it under a minimum-evidence policy, apply a visible uncertainty penalty, or require a low-value trial.
The chosen service should be explainable without replaying the model's private reasoning: “Candidate B was the only qualified offer under $0.08 with the required schema, 24-hour source freshness, and an explicit replacement remedy” is an auditable decision.
Use a Bid Protocol, Not Free-Form Bargaining
Machine negotiation predates large language models. Reid G. Smith's 1980 Contract Net Protocol described task allocation through negotiation: a manager announces work, eligible contractors bid, and the manager awards the task. It was designed for distributed problem solving rather than modern commerce, but its message discipline remains useful.
Adapt the pattern into a procurement exchange:
Every revision should be structured and reference its parent. A quote needs more than a price:
Natural-language messages can explain why a term changed, but only the canonical quote revision should be eligible for authorization. This blocks a buyer from interpreting “we can probably do eight cents” as a binding offer and stops a seller from hiding a worse data policy inside conversational prose.
A Counteroffer Must Stay Inside Delegated Authority
Negotiation authority is narrower than spending authority. An agent may be allowed to ask for a discount without being allowed to change the asset, recipient, usage rights, or delivery definition.
Define a negotiation envelope with:
allowed counterparties and service classes;
price ceiling and, where relevant, minimum acceptable quantity;
fields the agent may change;
ranges for delivery time, volume, and contract duration;
prohibited data-use or exclusivity terms;
maximum rounds and negotiation expiry;
conditions that require human or secondary approval.
Apply every proposed revision to the original requirement, not only to the previous quote. Otherwise small changes can accumulate beyond the grant. Three individually valid delivery extensions can move a 90-second deadline to five minutes. A lower price can arrive with a different payee or weaker remedy. The policy engine should compute the complete final state after each counteroffer and fail closed on any unauthorized field.
Cap the number of rounds. Endless low-value bargaining can cost more in model calls, latency, and opportunity loss than the discount is worth. A rational stop rule compares the expected benefit of another round with its compute cost, deadline risk, and probability of losing the current offer.
Lock the Winning Quote Into a Buy Contract
An accepted quote becomes purchasable only after both commercial terms and buyer authority are bound into one immutable record.
The buy contract should include:
contract ID and version;
procurement-intent hash and winning-quote hash;
buyer, delegated agent, seller, resource, and payment recipient;
final amount or metered ceiling, asset, network, and expiry;
exact input or input digest;
delivery deadline and output commitment;
acceptance test version;
retry, refund, replacement, and dispute rules;
buyer approval or grant reference;
seller commitment and key identity;
idempotency key for one commercial purchase.
Any material change creates a new contract version and requires re-evaluation. Do not let the payment adapter silently substitute a different recipient, network, amount, resource, or expiry. Do not let the seller change the output schema after award without reopening acceptance.
This technical contract supports reproducibility; it is not automatically a legally enforceable agreement in every jurisdiction. Teams still need appropriate legal terms, entity identity, record retention, and dispute governance for their use case.
Payment Executes the Contract; It Must Not Rewrite It
When the winning resource returns an x402 payment requirement, the buyer compares it with the authorized contract before signing.
Check at least the resource, scheme, network, asset, amount or maximum, payTo, and validity window. The x402 Signed Offers & Receipts extension can sign an offer containing resourceUrl, offerType, network, amount, payTo, and validUntil. Those fields are useful payment evidence, but they are narrower than the buy contract. The SLA, data policy, acceptance test, and remedy need their own signed or hashed commercial record.
Choose the payment scheme after pricing is known:
exactfits a fixed, known charge;uptofits measured usage when the buyer authorizes a maximum and expects the seller to charge the actual amount;batch settlement may fit repeated high-volume purchases where individual onchain settlement would be inefficient.
For upto, the contract must define the meter, evidence, ceiling, and unconsumed authorization treatment. The maximum is not the final price. For every scheme, use the procurement contract ID as the business idempotency key so retries do not become new purchases.
Record authorization, payment submission, verification, settlement, and merchant order state separately. Payment success admits the request to execution. It does not close procurement.
Acceptance Is a Separate Procurement Decision
The seller must deliver against the same acceptance contract used during comparison.
MCP can provide a declared outputSchema, and a client can validate structured tool results against it. A2A can represent a service job as a Task, expose submitted/working/completed/failed states, and return outputs as Artifacts rather than relying on transient messages. These mechanisms make delivery easier to observe.
They do not answer whether the result is commercially acceptable. Use explicit transitions:
A buyer may reject a schema-valid result because its source data is stale, required fields contain unsupported claims, the file arrived after the deadline, or the seller used input data outside the agreed policy. Record the result digest, validation output, test version, decision, reason codes, and remedy request.
If payment is already settled, rejection may trigger a replacement, refund, credit, or manual dispute rather than reverse the original transaction automatically. That remedy should receive its own ID and remain linked to the buy contract.
Worked Procurement: Buying a Research Result
Consider a hypothetical agent that needs one structured company-risk brief within 90 seconds. Every claim must reference a source observed within the last 24 hours, the result must conform to risk_brief_v3, input retention cannot exceed 24 hours, and total spend cannot exceed $0.08.
Discovery produces three candidates:
Candidate | Initial terms | Qualification result |
|---|---|---|
A | $0.03 per call; no output schema; data-use terms absent | Rejected: output and data-policy requirements not met |
B | $0.09 per accepted result; required schema; 75-second delivery; replacement or refund | Qualified but above budget |
C | Up to $0.06 per task; required schema; three-minute delivery | Rejected: misses hard deadline |
Candidate B is not the cheapest listed service, but it is the only negotiable qualified service. The buyer's policy permits one price counteroffer without changing data, acceptance, recipient, asset, or remedy terms. It offers $0.08 with the original 75-second delivery. The seller returns a signed revision accepting that amount.
The procurement engine then:
hashes the intent and final quote;
verifies the quote is unexpired and the seller key is authorized;
obtains buyer approval because $0.08 is above the $0.07 auto-accept threshold;
creates the buy contract and idempotency key;
compares the live x402 requirement with the contract;
pays only after every payment field matches;
submits the research input;
validates the returned schema, source references, freshness, deadline, and result digest;
accepts the result or invokes the stated remedy.
The prices and service attributes are illustrative. The useful point is the decision trace: the winner was not chosen by headline price, the counteroffer could not weaken non-price terms, and payment did not imply acceptance.
Map Identity, Runtime, and Commerce Infrastructure to the Loop
GOAT Network's current agent tooling can support several procurement stages without replacing the procurement engine.
Candidate identity and service metadata: AgentKit's ERC-8004 integration supports agent registration, machine-readable service entries for interfaces such as A2A, MCP, and x402, agent-wallet references, feedback, and reputation queries. These records can help discovery and qualification. The buyer still verifies current endpoints, terms, and task relevance.
Controlled execution: AgentKit Runtime documents network allowlists, action support, write permissions, risk/confirmation gates, input and output validation, trace IDs, idempotency, retries, timeouts, metrics, and hooks. These controls can govern calls and payment actions. They are not a complete procurement budget or quote-negotiation policy; applications must add business-specific limits and approvals.
Payment and merchant operations: GOAT Flow for AgentKit currently exposes five payer-side actions for creating, authorizing, transferring, checking, and cancelling payments. Its merchant-side plugin exposes thirty operations across authentication, orders, balances, webhooks, API keys, and related portal functions. Those surfaces can execute and operate the awarded purchase.
The missing layer remains deliberate: requirements, candidate normalization, bid logic, contract revision, seller selection, budget reservation, acceptance tests, and remedies belong to the procurement application. This makes GOAT relevant as composable infrastructure rather than an overstated all-in-one purchasing oracle.
Procurement Failures Reveal Which State Is Missing
Failure | What the buyer sees | Missing or broken control |
|---|---|---|
Catalog data is stale | Live quote differs from listing | Timestamped descriptor plus fresh RFQ |
Billing units differ | Cheapest offer produces higher total cost | Normalized billable event and workload |
Seller lowers price but changes data rights | Score improves while policy is violated | Full-revision validation against original intent |
Quote expires during approval | Payment requirement no longer matches | Expiry check immediately before signing |
Payment destination changes | Agent is asked to pay another address | Seller/payee binding and reauthorization |
Retry creates two purchases | Two valid payments for one task | Contract-level idempotency |
Payment settles but service fails | Paid order has no acceptable result | Separate execution, delivery, and remedy states |
Output passes schema but is stale | Technically valid, commercially useless result | Versioned semantic acceptance tests |
Reputation is manipulated | High score selects a weak provider | Signal provenance, task relevance, and low-value trials |
The state machine turns each incident into a local diagnosis. “The agent made a bad purchase” is too broad to repair. “The normalizer treated an authorization ceiling as final cost” or “the counteroffer validator checked only changed fields” identifies the failing component.
A Reference Buy Loop for Production
A production implementation can follow this order:
Create one procurement intent and immutable requirement version.
Discover broadly, then verify endpoints and identity references.
Apply hard qualification rules before price scoring.
Issue a structured RFQ tied to the intent hash.
Normalize quotes to one workload and evidence model.
Negotiate only fields and ranges allowed by the delegated policy.
Revalidate the complete revision after every counteroffer.
Award one quote and lock it into a versioned buy contract.
Reserve budget and obtain any required approval.
Compare the live payment requirement with the contract at sign time.
Execute payment once under a business idempotency key.
Track service execution and delivery independently from settlement.
Run the specified acceptance tests and record reason codes.
Accept, reject, or start the contract's remedy path.
Reconcile intent, quote, approval, payment, result, and remedy records.
Every step should emit a durable event with the same procurement ID. If an agent cannot explain why a candidate qualified, which quote revision won, what the owner authorized, and which evidence passed acceptance, it should not move to the next financial state.
FAQ
What is machine-to-machine procurement?
Machine-to-machine procurement is a workflow in which software agents discover services, compare normalized offers, exchange bounded quotes or counteroffers, obtain purchase authority, pay, and verify delivery. It is broader than agent payments because it includes the commercial decision before payment and acceptance after delivery.
How can AI agents compare services with different pricing models?
They should normalize each offer to the same workload and separate the billable event, quantity, fixed charge, unit rate, maximum authorization, expected fees, delivery terms, evidence, and remedy. Hard requirements are applied before a weighted score so a low price cannot offset an unacceptable schema, deadline, or data policy.
Can AI agents negotiate service prices automatically?
Yes, within explicit delegated boundaries. The policy should define counterparties, mutable fields, price and delivery ranges, prohibited terms, maximum rounds, expiry, and approval thresholds. Any final revision outside those rules must be denied or escalated rather than paid automatically.
Is x402 a procurement or negotiation protocol?
x402 is primarily an HTTP-native payment protocol, with optional extensions for capabilities such as discovery and signed offers or receipts. It can carry payment requirements and execute an awarded purchase, but it does not by itself define the full RFQ, comparison, negotiation, SLA, acceptance, or remedy contract.
How should an agent verify that a purchased service was delivered?
The buyer should link the result to the buy contract, verify the result or artifact digest, validate the declared schema, run the agreed semantic acceptance tests, check deadline and data-policy conditions, and record acceptance or rejection. Payment confirmation and a successful transport response are not enough.
Which infrastructure layers does an AI procurement agent need?
It needs service discovery and identity, capability and task interfaces, a comparison and negotiation engine, delegated policy, wallet and payment rails, merchant order operations, delivery evidence, acceptance logic, and reconciliation. These layers can come from multiple providers as long as they share stable contract and correlation identifiers.
The Buy Contract Makes Procurement Reproducible
Machine buyers should not optimize for the shortest path from search result to payment. They should optimize for the shortest verifiable path from need to accepted outcome.
That path is controlled by the buy contract. It explains why a candidate was eligible, which terms were negotiated, what the principal authorized, how the payment matched the award, and why the result was accepted or remedied. A wallet can execute one step. Procurement becomes reliable only when the entire loop can be replayed without asking the model to remember what it meant.
