Agentic Commerce

Commercial participants and responsibilities

The buyer seeks goods or services; the merchant is the business selling them. A buyer agent assists the buyer, while a seller agent performs merchant work. An agent operator runs the software. A marketplace intermediary connects buyers with participating merchants. These roles can overlap, but operating software and possessing authority to represent someone are distinct relationships. [1]

Checkout finalizes and submits purchase details. Fulfillment carries out the promised delivery or service. A dispute contests a transaction or obligation. Automating the preceding work does not collapse these boundaries: recommendation, buyer permission, merchant acceptance, payment, and fulfillment establish different things. [2][3][4]

Commercial incentives and selection influence

The principal–agent problem arises when a representative's incentives diverge from the participant's interests. For shopping software, this concerns its operators and commercial relationships, not presumed personal motives inside the model. Monitoring and incentive design can reduce divergence, but they also cost effort. The economic agency framework makes representation a relationship to inspect. [8]

Participation determines which merchants enter the available set; product selection chooses an item; merchant ranking orders sellers of that item. OpenAI's September 2025 checkout announcement described merchant purchase fees and asserted that they did not influence product results. Separately, its merchant-ranking factors included checkout availability. Those are provider statements about different decisions, not an independent ranking audit. [7]

Information asymmetry means unequal access to decision-relevant facts. In Cain's laboratory coin-valuation experiment, advisers inspected jars more closely than estimators. Some advisers earned more by inducing high estimates. Disclosing that conflict did not remove its effects: advice became more exaggerated and estimation errors grew. This bounded result explains why disclosure cannot substitute for examining incentives. [10]

Clear disclosure still matters. U.S. FTC guidance calls for conspicuous explanation of affiliate relationships near recommendations. Machine-readable presentation also leaves selection influence possible: ACES found model-dependent position effects and successful seller-description edits in simulated shopping. Position effects also appeared in tested JSON-only interfaces. Its selection frequencies were neither paid sales nor measurements of buyer welfare. [9][11]

Buyer requirements and unresolved preferences

A defensible comparison distinguishes hard requirements, which a purchase must satisfy, from preferences that permit tradeoffs and unknowns that need clarification. A personal agent works across a person's tasks and applications; remembered preferences can help interpret a request, but cannot establish permission to spend. Personal Agents develops that broader relationship. [12][13]

A buyer requests one pair of shoes for an event, accepts either of two styles, and also requires specified socks. The request still needs the correct size, compatibility with the intended activity, destination, arrival deadline, and complete budget. Permitted alternatives describe what may qualify; they do not justify inventing missing requirements. [14]

Products, variants, and current merchant offers

A product family groups related items; a variant specifies attributes such as size or color. Google's published shirt example has three sizes and three colors, producing nine variants. Matching the family name does not identify the required variant. Variant identifiers preserve that distinction. [15]

An offer adds a merchant's commercial terms to an item. A SKU, or stock-keeping unit, is a merchant-specific identifier, not a universal product identity. The Offer vocabulary separates item identity from seller, price, currency, availability, shipping, and validity. [18]

Catalogs, feeds, APIs, and storefront observations expose candidates. Search finds material relevant to an information need; Information needs and retrieval stages explains the mechanism. Shopping results may omit products, simplify descriptions, or lag merchant changes. Preserve the source and observation time so a retrieved listing does not masquerade as a fresh commitment. [12]

A preorder concerns an unreleased product; a backorder accepts an order for a temporarily unavailable product. Neither means stock is ready to dispatch. Availability guidance ties these states to dates and supported destinations. An in-stock statement is still different from inventory reserved for this buyer. [16][19]

Comparison on complete commercial terms

Multi-criteria comparison first excludes offers that fail requirements, then weighs preferences among acceptable choices. A displayed price may omit decisive costs or obligations. Unknown tax, destination eligibility, or arrival timing stays unknown; it cannot become zero cost or assumed eligibility merely to produce a ranking. [18][12]

Offer B cannot yet be established as cheaper or timely. Dispatch lead time ends at shipment or pickup preparation, not arrival. If A later loses stock, its earlier recommendation also needs revision: a preserved price does not preserve availability. The comparison identifies an acceptable candidate under observed terms; purchasing permission remains a separate decision. [18][19][6]

Delegated purchasing authority

Delegated authority is permission to make specified commitments for another participant. A purchase mandate records its commercial scope. Research, cart preparation, purchase, cancellation, and replacement are different actions. Account access or a remembered approval cannot silently expand that scope. [20][21]

AP2 v0.2 links Checkout and Payment Mandates. Direct approval concerns a specific checkout; autonomous purchasing operates within approved constraints. Deterministic code verifies mandates. This separates choosing a purchase from establishing permission to execute it. [6]

An open Checkout Mandate can allow specified alternatives; a closed mandate binds a merchant-signed checkout by its hash. The published substitution example permits one of two shoe styles together with required socks. Its open-mandate line-item rules do not support splitting the mandate across multiple checkouts. [14]

Standing authority also needs history: permitted payees and instruments, currency, amount bounds, execution dates, recurrence frequency, occurrence limits, and cumulative spending. Payment Mandate constraints require accounting for prior approved amounts. A per-purchase ceiling alone cannot enforce a total allowance. [17]

Changed terms must satisfy the existing permission or receive renewed approval. Expiry or withdrawal blocks new execution; neither establishes that an earlier commitment disappeared. Approval bindings must survive retries and callbacks. Approval, changing state, and retries explains the general execution boundary. [21][22]

Identity, integrity, and commercial trust

A verifiable credential is a tamper-evident statement with cryptographically checkable authorship. Verification checks authenticity, status, and applicable technical requirements; business validation decides whether the issuer's claims satisfy the recipient's needs. Neither a valid signature nor recognizable authorship establishes that the claims are true. [23]

Signed transaction artifacts can preserve continuity between terms and receipts. Froglet's presentation describes signing descriptors, offers, quotes, deals, invoices, and receipts. The described chain supports an integrity objective; its signing details do not establish product quality, completed delivery, or correctness of delivered work. [24]

Prompt injection attempts to turn untrusted content into behavioral instructions. A merchant listing could instruct a shopping agent to replace required socks or send buyer details elsewhere. That constructed threat applies the mechanism in Prompt injection and instruction authority: relevant content remains data, and cannot confer permission to substitute goods or disclose information. [25]

Disclosure should match the task: browsing need not expose every customer field. Remove unnecessary fields before model access, and authorize merchant disclosures independently. Access and disclosure boundaries covers that control. Necessary transaction signals can still reach sellers; the payment-infrastructure talk describes preserving selected card metadata for existing merchant risk checks. [26][27]

Checkout and merchant acceptance

A cart collects proposed items. A quote states proposed terms. Neither necessarily commits inventory or establishes merchant acceptance. Checkout refreshes quantities, destination, complete price, currency, delivery, and recurring terms. The payment-infrastructure presentation illustrates structured seller responses after checkout changes. A generated tool request still requires application execution and validation. [28][29]

Seller agents also need merchant-controlled limits on discounts, substitutions, inventory, and promises. A venue assistant described in the tone-layering talk offered an already booked date without calendar access. Checking generated claims against authoritative allowed values can block that wording; actually reserving the date requires a separate merchant operation. [30]

An acknowledgment may establish receipt of a submission without acceptance. Apple's U.S. education-store terms explicitly make that distinction. Each merchant integration therefore needs its own acceptance semantics; an email subject or generic success flag is insufficient. [31]

The ACP lifecycle defines completion as payment success and order creation. Processing locks the session; completed-session cancellation is unavailable. [2]

Payment permission and financial state

A payment credential enables use of a payment method. A payment service provider processes payment activity for a merchant. Credential scope can be narrower than purchasing permission: shared payment tokens constrain seller, amount, currency, and expiry, but do not encode every item or delivery requirement. Bank authentication may still be required. [32]

The figure uses Adyen's card-payment lifecycle. An uncaptured authorization can expire or be canceled. Decline, pending processing, collection, and refund are different outcomes; sequencing varies by payment method. [33]

Financial progress answers a money question. It cannot establish that the buyer authorized the particular items, the merchant accepted them, or delivery occurred. A successful purchase therefore needs linked but separately interpreted permission, order, payment, and fulfillment records. [20][31][34]

Persistent purchases and uncertain outcomes

A purchase survives individual agent runs. Its business state records established obligations; an execution attempt records activity toward them. Cases and authoritative state explains this separation. Preserve the identifiers needed to reconstruct the purchase rather than treating the conversation as its system of record. [35]

Reconciliation resolves recorded uncertainty against authoritative external records. A payment timeout can conceal an executed request, and even a cached server error can coexist with side effects. Preserve correlation identifiers and pending state until provider evidence resolves the outcome. The same reasoning applies when a merchant accepts an order before its response is lost. [37][38]

Idempotency means the receiving service recognizes repeated requests as one logical operation and avoids repeating its effect under a defined contract. A key merely written to a log supplies no such enforcement. The service must coordinate the mutation with its deduplication record; identical parameters alone cannot distinguish a retry from an intentional second purchase. [38]

Stripe's documented v1-style contract reuses a key with identical parameters and returns the first executed response, including errors. Validation failures and concurrent conflicts before execution do not save a result. Keys may be pruned after at least 24 hours; reuse after pruning starts a new request. These conditions are provider-specific, not permanent exactly-once purchasing. [39]

Duplicate prevention and permission must both hold. If the original request never began, a retry can initiate the effect. Expired approval therefore cannot be rescued by reusing its key. Reconcile first through an authorized read; then either record the existing effect or obtain the permission needed for further execution. Expiry does not undo an earlier purchase. [39][22]

Concurrent buyers can each observe the same remaining allowance and jointly exceed it. Uncertain commitments also consume potential exposure. A safe design needs coordinated spending reservations and an explicit rule for releasing them; AP2's cumulative accounting requirement alone does not demonstrate that enforcement. Budget coordination and uncertain effects explain the runtime foundations. [17]

Fulfillment and outstanding obligations

A line item records an item and quantity. A fulfillment group assigns items to delivery work; a shipment records goods sent. Partial fulfillment leaves some quantities outstanding. Shopify's order model separates these records. A delivery exception interrupts planned delivery; it does not erase the obligation. [3]

Completion evidence depends on what was purchased. Physical goods require evidence beyond shipment creation; digital goods may require access or download records; booked services need appointment or work records. Even a delivery report does not establish that the goods conformed to the agreed description. [40]

The merchant coordinates its promises, carriers transport goods, platforms expose records, and support teams resolve exceptions. Assign one operational owner while work remains unresolved. A sent escalation does not transfer responsibility: the recipient must accept it and possess the ability to act. Accepted handoffs explains that distinction. [41]

Cancellations, returns, and refunds

A compensating action is a new action addressing an earlier external effect. Canceling an order, stopping shipment, returning goods, releasing a payment hold, and refunding collected money affect different records. Stopping the agent cannot establish any of those outcomes. Partial completion and business recovery covers the general pattern. [42]

A refund returns money through a separate financial operation. In Stripe's refund flow, initiation submits a request to the customer's bank or issuer; visible credit comes later. Refunds can fail, while a reversal can instead remove the original charge. Preserve the recovery identifier and link it to the original payment until the outcome is established. [43]

Eligibility, fees, deadlines, and linked obligations require the applicable merchant terms. Apple's education-store terms warn that returning a device need not cancel its separate wireless agreement. The same purchase record may therefore need to track returned goods, financial recovery, and an ongoing service obligation independently. [31]

Disputes and accountable resolution

A routine service request seeks assistance; a dispute contests authorization, charges, receipt, or conformity. In a card chargeback, the cardholder's bank—the issuer—uses the card network, which connects payment participants, to initiate a formal dispute and reverse payment. This differs from a merchant-issued refund; the initial reversal is not final adjudication. Stripe's dispute overview describes this process. [4]

Keep event time separate from observation time. A dispute can appear well after payment, and its outcome can remain unresolved through evidence submission and issuer review. At an evaluation cutoff, no observed dispute means none has been recorded by then—not confirmed absence of fraud or dissatisfaction. [44]

Provenance records where evidence came from and how it changed. Preserve the terms, decisions, and versions necessary for review while limiting personal data, access, and retention. Lineage and proportionate audit evidence explains this balance. An investigation record supports accountable decisions without independently determining legal liability. [45]

Autonomy models and commercial usefulness

Greater variability, difficult reversal, or high potential loss increases the value of reviewing a concrete commitment. Repeated, well-specified purchases can support narrower standing rules. Integration quality matters: reliable permission checks are insufficient when current offers, external outcomes, or recovery paths cannot be established. [13][37]

Operating ownership must cover more than model behavior. Merchants maintain catalog and fulfillment information; buyers define purchasing intent; operators maintain execution controls. Assign checkout exceptions, support, and disputes explicitly. Registration, authorization, monitoring, investigation, and revocation are ongoing responsibilities when software can create consequential side effects. [46]

Compare autonomy models on similar purchase populations and merchant policies, including exception handling and later outcomes. Selection frequency, conversion, and agent activity are incomplete proxies. Evaluation boundaries and total operating work provide the measurement foundations. A useful deployment reduces work or improves outcomes without hiding costs and unresolved obligations elsewhere. [11][47]

Open questions

1. 01

   Concurrent standing authority needs enforceable exposure accounting. Independent checks can overspend shared limits, while uncertain effects make capacity release unsafe. Progress requires demonstrated reservations, revocation handling, and recovery under simultaneous requests and lost responses. [17][39]

2. 02

   Merchant recovery semantics remain difficult to normalize. Acknowledgment, acceptance, cancellation, and linked services can follow different contracts. Progress would be an end-to-end integration that identifies each acceptance event and verifies recovery without silently leaving associated obligations active. [31][43]

3. 03

   The comparative value of autonomy models remains unsettled. Simulated selection cannot establish real buyer benefit, and easier purchasing can shift work into returns or support. Progress requires matched field comparisons covering total effort, suitability, merchant economics, and unresolved cases through a meaningful follow-up period. [11][44]

4. 04

   Accountability across operators and commercial participants needs more than linked receipts. Records can explain authorization and events while leaving liability, retrieval duties, and resolution procedures unspecified. Progress requires explicit responsibility agreements exercised in contested cases with proportionate evidence access. [6][45]