How Agentic Commerce Works

The pipeline, stage by stage

1. Intent. A person states a goal: reorder printer paper, book a table, buy a dataset. The agent turns that into constraints it can act on: item, quantity, budget, delivery window, acceptable sellers.

2. Discovery. The agent finds candidates. For goods this means structured product data from merchants or catalogues; for services and APIs it means descriptions of what is offered and at what price. Anything the agent cannot parse, it cannot buy.

3. Selection. The agent compares candidates against the constraints. This is where most judgement lives, and where the agent is most exposed to manipulation, since a merchant's product description is untrusted input.

4. Authorisation. Before paying, the agent needs a mandate: evidence that the person approved this purchase, or a category of purchases within limits. This can be a live approval or a standing permission with a cap.

5. Checkout and payment. The agent submits the order and pays, either through a merchant checkout flow using a delegated payment credential, or by settling directly, for example in a stablecoin.

6. Fulfilment and follow-up. Confirmation, shipping, delivery, and any returns or disputes. For API purchases this stage collapses to receiving the response. For goods it can take days and involve people.

What each side has to build

Merchants.

• Machine readable product data with accurate prices, availability, and terms, updated often enough that an agent does not buy something out of stock.
• A checkout an agent can complete without a browser session designed for people, or support for a protocol that provides one.
• A way to accept payment from an agent, and a clear policy for returns and disputes when the buyer is software acting for a person.

Agent builders.

• Constraint extraction that turns a vague request into limits the agent will actually respect.
• Selection that treats merchant content as untrusted and cannot be talked into a higher price or a different seller.
• Authorisation records that prove what the person approved, stored with every purchase.
• Payment through a credential or account that is bounded by amount and scope.

Payment providers.

• Credentials that can be delegated to an agent with limits, or settlement rails that an agent can use from a bounded balance.
• Signals that let a merchant distinguish an authorised agent from a fraudulent one.

Where it goes wrong

The agent buys the wrong thing. Ambiguous intent, a misleading listing, or a substitution the person would not accept. The fix is tighter constraints and confirmation for anything outside them.

Nobody can prove what was authorised. A dispute arrives and the only record is a chat transcript. Authorisation needs to be captured as a structured, signed record at the moment of purchase.

The payment credential is too powerful. An agent holding an unrestricted card or key can be manipulated into large or repeated purchases. Scope and cap every credential.

Fulfilment fails after payment. Out of stock, delayed, or wrong item. With card payments, dispute processes exist. With final settlement such as a stablecoin transfer, recourse depends on the merchant's policy, which the agent should check before paying.

Merchants cannot tell good agents from bad ones. Without a way to verify that an agent acts for a real, consenting person, merchants either block agents entirely or absorb fraud.

API and data purchases avoid most of these because delivery is immediate and the price is the whole contract. That is why agent payments started there, and why buying physical goods remains the harder case.