Agentic Commerce: What to Build Now, What to Skip

A customer tells their assistant to book a meeting room in Tel Aviv for Thursday, under ₪400, with parking. The assistant compares three venues, picks one, pays, and puts it on the calendar. Nobody ever opened your site.

That is agentic commerce, and the plumbing for it arrived faster than the demand. Five or six competing specifications now exist for how an AI agent discovers a product, builds a cart, and pays — and the honest read is that none of them has won. Which makes this an easy quarter for product teams, because the work that matters is not protocol work.

Four Specs, No Winner Yet

What each layer actually covers

The Agentic Commerce Protocol, open-sourced by OpenAI and Stripe, handles the commerce conversation: discovery, cart, checkout. Its mechanism is a Shared Payment Token — a scoped, time-limited credential good for one amount at one seller, so the agent never holds a card number.

Google and Shopify’s Universal Commerce Protocol covers a wider arc, discovery through post-purchase support, with the merchant staying merchant-of-record. Google’s Agent Payments Protocol sits underneath both and answers a different question: how do you prove a human authorized a payment when no human is at the keyboard? Its answer is cryptographically signed mandates — a checkout mandate covering the negotiated cart, a payment mandate covering the instrument, chained together into an auditable trail. And x402, now under a Linux Foundation body, revives HTTP 402 for machine-to-machine stablecoin payments.

Underneath all of it sits MCP as the discovery layer, which is where a merchant advertises checkout as a callable tool.

Why committing now is a bad bet

AP2 is still pre-1.0 and is being folded into FIDO Alliance working groups. ACP is in beta. UCP shipped its first spec this year. The adoption numbers quoted at launch have mostly not materialised. Building against a moving spec means you maintain it forever and get paid for it never.

So skip the specs. Build the four things every one of them assumes you already did.

Make Price and Availability Queryable

An agent cannot read your pricing page

If your real price depends on a quantity dropdown, a promo banner, and a tooltip, an agent will get it wrong — and the one it quotes to the customer is the one you will be asked to honour. Price, stock, fees, and delivery windows need to come from an endpoint that returns the same answer your checkout would.

Most teams discover their pricing logic lives in four places at once. On Meetinkz the pricing engine had to resolve hourly rates, corporate budget rules, and minimum bookings into one number before anything could quote it reliably. That consolidation is useful with or without agents.

Quote, hold, confirm — not one call

Agents compare before they commit, often across several sellers. A single create-order endpoint forces them to guess. Split it: a quote that is binding for a stated window, an optional hold, then a confirm. The structured-output discipline that keeps model responses parseable applies in reverse here — your responses need fixed shapes and explicit units, not prose.

Assume Every Call Gets Retried

Idempotency is not optional any more

A browser retry costs a human thirty seconds of annoyance. An agent retry costs nothing, so agents retry hard. Require an idempotency key on order and payment creation and return the first result for a repeat key. Teams that skip this find duplicate orders in week one.

Scope the credential to one order

Every payment spec in this space converges on narrow, short-lived, single-purpose credentials. If your API has one key that can do everything, you cannot represent that, and you inherit the whole blast radius problem instead of containing it. Per-order scopes, per-agent identities, hard expiry.

Keep Proof of Who Agreed to What

Store the authorization, not just the order

When a charge is disputed and no human was present, your evidence is the authorization record: which agent, acting for whom, under what limits, signed off on what cart. Store it alongside the order from day one. The same instinct behind dated consent proof under Amendment 13 applies — the record is worth more than the feature.

Decide your agent policy before your WAF does

Right now a default bot rule is probably turning away agents that were about to pay you, while letting through scrapers that take your catalogue for free. Those are different decisions. Write the policy, put it in robots.txt and your bot rules, and log the refusals so you can see what you are declining.

None of this is speculative infrastructure. Queryable prices, a quote-hold-confirm flow, idempotent writes, scoped credentials, and a stored authorization trail are things a well-built SaaS platform should have regardless. Agent traffic just removes your ability to postpone them. If you want that groundwork laid properly while you build, it is how we scope AI development work. Tell us what you are building.

Yaniv Amrami is founder of quickdev. He builds marketplace, booking, and payment platforms for Israeli companies, where the quote-and-confirm flow is usually the hardest part of the system.