Agent-to-Agent Commerce: Identity, Work Acceptance, and Payment Settlement Requirements

Suppose an agent buys a research report from another agent. The payment is confirmed and a document arrives, but it uses the wrong input period and omits an agreed source. The provider has delivered something. The buyer has paid. Whether the job passed is still a separate decision.

This hypothetical illustrates the requirements problem in agent-to-agent commerce: one agent purchases another's service, but identity, permission, acceptable work and settlement each need their own evidence. A payment protocol can help move value without deciding whether a report met its brief.

A useful reference architecture therefore starts with the work agreement. It connects that agreement to authorized actors, a recorded acceptance decision and separate payment and delivery records. The requirements below explain those responsibilities, not certify a particular deployment.

Agree What Counts as Accepted Work

Before choosing a verifier, specify what the buyer is purchasing. A request to "research this market" leaves too much room for incompatible judgments. An agreement should identify the input snapshot, required deliverable, relevant period, evidence requirements and treatment of incomplete work. The provider and evaluator need the same version of those terms.

For the hypothetical report, requiring named sources and the correct period makes some checks repeatable. Assessing whether the analysis is persuasive needs a different rubric. Combining the two under one unexplained "verified" flag conceals what was actually checked.

A conceptual job record should connect:

• Agreement: the parties, saved inputs, deliverable specification and accepted version of the terms.

• Evaluation: the criteria or rubric, evaluator identity, policy version and authority to decide this job.

• Evidence: the submitted artifact, its version or content commitment, and the material used to evaluate it.

• Decision: accepted, rejected or partially accepted, with the reason and any unresolved disagreement.

• Financial consequence: who may release escrow, authorize a refund or approve a revised agreement, and under what conditions.

These are engineering requirements for the application, not a universal record format mandated by ERC-8004 or x402. Their purpose is to make a decision reproducible enough to inspect and challenge. A new submission should not silently replace the artifact an earlier acceptance refers to.

Evaluator authority matters as much as evaluator identity. The buyer might authorize an evaluator to reject a malformed report but reserve subjective disagreements for a named reviewer. The agreement should say which decisions are binding, what happens when the evaluator is unavailable and whether partial acceptance changes the amount due. Otherwise an automated result can trigger a financial action nobody explicitly authorized.

A content hash helps identify the exact bytes considered. It does not establish that a report is accurate, useful or honestly evaluated. Reputation serves another purpose: past feedback can help select a provider, but it does not decide whether this deliverable passed this agreement.

The distinction appears in the September 24, 2026 KULT announcement. GOAT reported that KULT's first agent job funded escrow with 0.25 USDC and, after a verifier accepted the work, distributed 0.225 USDC to the provider and 0.025 USDC in commission. In that account, GOAT Flow handles payment; KULT handles identity, the agreement, work verification, conditional escrow and work history.

That is a dated first-party report, not an independently verified transaction or work-quality assessment. The announcement describes the verifier as independent; it does not establish measured evaluator reliability or independently demonstrated freedom from conflicts. Its value here is the explicit division of responsibilities, not proof that every evaluation is correct.

KULT's escrow and callback arrangement is also case-specific. It does not establish that the same callback mode is available to every GOAT Flow merchant, or that x402 automatically provides escrow. Current public Flow merchant examples use DIRECT transfers; the case should not be treated as a universal integration contract.

An acceptance decision and an escrow release should remain distinguishable even when software connects them. The former applies the work criteria; the latter exercises financial authority under the contract. A failed transfer does not reverse the evaluation, and a completed transfer does not settle a dispute about its basis.

Identify the Actor and Bound the Mandate

Once the agreement is clear, identify who may commit each party to it. The agent named in a registry, the owner managing that record, the receiving wallet and the signer authorized to spend may be different technical actors. None should silently stand in for the others.

As of November 3, 2026, ERC-8004 remains a Draft specification. It describes an agent identity through a registry reference containing the chain family, chain ID and registry address, together with an agent ID. Retaining only the numeric agent ID loses the context needed to identify the record. Its registration-v1 label identifies the registration-file format, not a production certification.

The Identity Registry uses ERC-721 ownership and management permissions. Those permissions let an owner or approved operator manage the agent record; they are not a general mandate to spend a customer's funds. A receiving-wallet binding likewise concerns where funds may be received. It does not establish the operator's legal entity identity, or authorize that wallet to purchase services for another principal. Legal or organizational accountability requires whatever additional evidence the parties' relationship demands.

For a proposed job, the principal's mandate should specify the permitted action and resource, recipients, asset and network, expiry, per-job limit and cumulative budget. It also needs an enforcement location. A spending limit written in an agent prompt is different from a restriction enforced by the component that can sign or execute the payment. Identify the component that refuses an unauthorized action and the person or service able to revoke its authority.

GOAT AgentKit provides a concrete tooling boundary. The AgentKit ERC-8004 guide documents network-aware Identity and Reputation registry mappings and actions for registration, metadata, receiving-wallet lookup and feedback queries. The published AgentKit 0.3.0 package archive contains identity/reputation and x402 payment modules. These are documented capabilities and static package contents, not evidence that a particular agent has successfully executed them together.

The same distinction applies to local runtime policy checks. Network allowlists, write restrictions and confirmation requirements can constrain action dispatch, but their presence does not demonstrate a cumulative spending-budget implementation, a custody guarantee or exactly-once external effects. The principal still needs deployment-specific evidence that its actual mandate is enforced.

ERC-8004's validation design requires similar care. The reference contracts repository contains Validation Registry code while warning that the Validation portion remains under revision. Reference code and a documented Identity/Reputation mapping do not establish a deployed GOAT Validation Registry or a working validation-to-escrow integration. They also do not justify claiming that no Validation implementation exists anywhere.

Authority must survive changes safely. After a compromised signer or key rotation, an operator should suspend affected jobs, revoke the actual signing or session authority, reconcile outstanding payment attempts and review identity, endpoint and receiving-wallet bindings. Updating a payout address alone does not remove an attacker's existing permissions. Record who owns that incident decision and which unfinished jobs remain blocked.

Track Payment and Work as Separate States

Payment evidence becomes useful when its meaning is specific. A quote, signed payload, verification response and confirmed transfer are observations at different stages. Treating all of them as "paid" makes both fulfillment and recovery harder to reason about.

The x402 V2 HTTP transport separates payment requirements, the client's signed payment payload and a settlement response. A server communicates terms through PAYMENT-REQUIRED; the client retries with PAYMENT-SIGNATURE; PAYMENT-RESPONSE communicates the settlement attempt's outcome. That last response can report failure as well as success. Its existence alone is not a successful-payment verdict.

The client must evaluate the terms before authorizing them: amount, asset, recipient, network and payment scheme need to fit the mandate. A signed authorization shows consent under that mechanism; it is not interchangeable with evidence that funds have moved. Settlement timing also depends on the scheme. The transport documentation distinguishes schemes that typically settle immediately from batch settlement that authorizes first and redeems value on-chain later. There is no universal same-round-trip finality rule.

The application should preserve these distinctions alongside its work records:

This is an interpretation model, not a new protocol schema. Store payment state, delivery state and acceptance state separately, linked to the same logical purchase. A report can be paid for but unavailable, delivered but rejected, or accepted while a payment outcome remains unresolved. An application deadline may require manual review without changing the network's settlement state.

The current GOAT Flow API Payments contract makes the access boundary explicit. Its MPP profile uses a GOAT-specific challenge and receipt interface. A merchant needs deployment-matched enablement, an approved client/verifier, the trusted verification key and shared receipt-consumption state. Middleware installation alone does not enable the merchant or paid route, and an arbitrary MPP implementation cannot be assumed compatible.

Receipt verification does not authenticate the current customer or prove ownership of the paid operation. The application must connect the verified receipt to its server-side purchase record, authorized requester, saved inputs and permitted result. A receipt valid for a report route must not unlock another customer's report or a more expensive operation on that route. Authentication and request/ownership checks should precede payment middleware, with receipt-dependent business checks before delivery.

That division still stops short of judging work quality. GOAT Flow supplies payment requirements, order and receipt services; the service application owns its business authorization and fulfillment. The evaluator's acceptance record answers a different question from either receipt validity or route access.

Finality needs its own network context. GOAT's security model distinguishes fast network confirmation from Bitcoin finality: sequencer feedback and the Bitcoin-backed publication/challenge boundary are not the same observation. That distinction is not a settlement-time SLA. The KULT announcement's transaction links point to Base, so those reported payments should not inherit GOAT or Bitcoin settlement properties merely because Flow was the payment product.

For each purchase, the operator should identify the network, payment scheme and evidence threshold used to proceed. If that threshold changes, retain the policy version associated with the earlier decision rather than rewriting history as if every payment had always followed the new rule.

Recover a Paid Job After a Missing Response

Return to the hypothetical research purchase, but change the failure. The buyer sends its signed payment payload, then loses the HTTP response. It has neither the report nor a usable payment outcome. Automatically signing again may create another charge while the original job is already running.

The x402 client/server retry guidance treats a timeout after payment submission as an unknown outcome, not proof of failure. It also distinguishes payment state from an application's decision to stop waiting. An expired authorization, exhausted retry budget or missing lookup result does not establish that an earlier transaction never settled.

Recovery needs a durable purchase record rather than a fresh checkout loop. Preserve the logical request and job IDs, saved inputs and payment-terms fingerprint, original order or challenge reference, receipt if available, transaction hash and network if known, observed outcome, last reconciliation attempt and saved delivery result. Include the application deadline and the policy that decides when automation stops. These are application records, not fields supplied universally by x402.

The subsequent decision has three branches. If payment is confirmed, recover the original operation's result through an authenticated result-retrieval path; do not charge again just to obtain another HTTP response. If delivery never completed, the operator must resolve fulfillment or refund under the agreement. Payment confirmation does not make missing work acceptable.

If the outcome is still unknown, continue reconciliation through the server or facilitator's available process. The HTTP transport does not define one universal settlement-status endpoint. When the application's deadline is reached, stop automatic replacement payments and assign the unresolved purchase for review. A business deadline can bound operational effort while the financial state remains unknown.

If settlement is conclusively unsuccessful, consider a new authorization only after checking whether repeating the underlying operation is safe. Re-evaluate changed prices, networks, assets, recipients or challenges against the mandate. A corrective payment-required response does not itself resolve an earlier attempt.

Receipt consumption introduces another recovery boundary. In Flow's documented profile, a receipt may already have been consumed before a later handler failure or lost response. The appropriate action is recovery of the saved result or fulfillment record, not another purchase. Replicated services need shared durable consumption state so separate instances cannot independently treat the same receipt as unused.

Single-use receipt checks and application idempotency solve related but different problems. The receipt controls payment-backed access; the fulfillment system must separately prevent concurrent polling, webhook processing or retries from duplicating work. Neither a local cache nor an idempotency label guarantees that an external action occurs exactly once. Preserve enough evidence to reconcile the action after a restart, and give an owner responsibility for effects that cannot safely be repeated.

Resolve Contested Work Without Exposing the Inputs

A recovered result may still be wrong. The report can fail its rubric, the evaluator can miss a defect, or the parties can disagree about a partially completed job. These are acceptance disputes, not payment-verification errors. Routing every complaint to the payment provider leaves the decision-maker undefined.

The agreement should assign who may challenge an evaluation, what evidence they can inspect, when a challenge closes and who may authorize release, refund or a revised submission. It should also specify the treatment of evaluator non-response. Those choices need to exist before money is locked in a conditional arrangement; they are not automatically supplied by having escrow.

An evaluator's signature identifies a decision source, not its correctness. Staking and reputation may create incentives, but neither alone establishes protection against collusion, fabricated feedback or Sybil identities. For contested evaluations, retain the criterion version, evidence considered, result and reason, together with a named escalation authority. If two evaluators disagree, the contract needs a rule for that disagreement rather than an unexplained assumption that another score resolves it.

Returned content creates a separate abuse path. A provider's report or tool response should remain untrusted input: instructions embedded in it must not gain the authority to change the rubric, choose a new payout recipient or trigger a signature. Isolate evaluation from payment execution, restrict evaluator capabilities and require financial actions to pass the principal's mandate. These are design requirements, not proof that a particular implementation withstands adversarial results.

Subcontracting makes ownership more demanding. A provider may pay another agent for a dataset that passes the sub-job's checks while the parent report still fails the buyer's coverage requirement. Record the parent/child agreement relationship and which evidence may be shared. Assign delivery, payment reconciliation and appeals to the relevant parties instead of treating every successful sub-job as acceptance of the parent deliverable. No universal cross-provider dispute procedure follows from the protocols discussed here.

Private evidence must remain available to the authorized reviewer without becoming public by default. Keep confidential inputs, outputs and credentials in access-controlled storage; use only the commitments or references necessary for the agreed verification and audit purpose. Public pointers and hashes can expose durable metadata even when the underlying document is private. Define who can retrieve evidence, how long it remains available and how an appeal proceeds if access expires.

That creates a real tradeoff: withholding all evidence can make a decision impossible to challenge, while publishing everything can irreversibly disclose sensitive relationships or work. Resolve the access policy as part of the agreement, not after the first disagreement. If the evaluator lacks required evidence, preserve that as an unresolved decision rather than silently marking the work passed.

For a proposed agent purchase, the useful completion test is concrete: an authorized actor can identify the agreement, the acceptance basis, the payment state and the person or service responsible for a disputed outcome. Where any of those remain unknown, the job needs a bounded recovery or review path, not an inferred success flag.