Agentic Commerce2026-08-1222 min read

Agentic Commerce Safe Actions: Confirm, Authorise, and Hand Off Without Guessing

An agent finding a product is not the same as an agent being allowed to act. Safe commerce separates discovery, eligibility, confirmation, commit, and receipt. At each boundary it carries the exact item, the evidence, the buyer context, the current offer, and the authority that permits the next step.

This guide is a vendor-neutral framework and test plan. It does not claim a universal Shopify agent checkout protocol or a native B2B agentic storefront. It shows how to keep a machine from turning a plausible search result into an unauthorised, stale, duplicated, or irreversible action. Start with the Agent Search Contract for the response shape, then use the action boundary below.

Decision rule: discovery may suggest, eligibility may qualify, confirmation may authorise, and commit may execute. Never let a result card imply all four.

Chapter 1 · The action model

Move from claim to commit through explicit gates

An agent can make a claim about a candidate before it has permission to change state. That separation is the safety mechanism. The search answer says what was found; the eligibility check says whether the buyer may act; confirmation says what the buyer accepts; the commit records the bounded change; the receipt makes success or recovery observable.

A safe action is a chain of proofs and permissions. The receipt is part of the action because a timeout must not look like permission to retry.

Bridge · From gates to decisions

Now follow one result to the first dangerous assumption

Imagine the first chapter has done its job: the search found a compatible variant, the buyer is known, and the current offer was checked. It is tempting to treat that complete-looking result as permission to add the item to cart. But “we found it” and “we may change state” are different claims, owned by different evidence and different authority.

Chapter 2 separates those jobs so the gates have somewhere to lead. First we define what discovery may safely say, then what selection requires, then what a commercial action must recheck. The result is not less useful. It is clear about which decision has actually been earned.

Chapter 2 · Separate the jobs

A recommendation is not an authorisation

Discovery can tolerate a bounded candidate set. An action cannot. A person may scan two compatible parts and choose one. An agent needs an explicit match state, the exact variant, the evidence for fitment, the buyer's eligibility, and a permission that covers the intended change. The parts and compatibility guide covers the proof before action; the B2B eligibility guide covers the buyer context.

Action	Minimum evidence	Authority	Decision
Explain or recommend a candidate	Relevant result with match state and evidence	Read scope	May proceed, labelled as discovery
Select an exact variant	Exact or confirmed match, variant identity, constraints intact	Read scope plus selection intent	Proceed only when selection is explicit
Add to cart	Eligibility, price, currency, availability, and variant revalidated	Explicit add-to-cart permission	Confirm if any commercial value or constraint changed
Submit an order or payment	Final offer, buyer, address, quantity, and total confirmed	Separate order authority and buyer confirmation	Stop unless all required authorisations are present

Chapter 3 · The safe-action contract

Carry the facts that make an action bounded

Keep the action record small enough to inspect and complete enough to prevent inference. The fields below are a framework for acceptance tests, not a claim about a universal API or a platform-native wire format.

Actor and authority

Ask: Who is asking, and what scope has been granted?

Safety rule: No identity or scope means no autonomous action.

Candidate identity

Ask: Which product and exact variant did the search resolve?

Safety rule: A product family is not enough. Carry the sellable variant.

Evidence

Ask: Why does this item satisfy the request or fitment constraints?

Safety rule: A score or title is not proof of a hard compatibility claim.

Eligibility context

Ask: Which market, customer, company location, catalogue, and currency apply?

Safety rule: Do not carry a public or stale context into a protected action.

Offer state

Ask: What price, availability, quantity, and expiry were checked?

Safety rule: Revalidate volatile values at the action boundary.

Confirmation and receipt

Ask: What did the buyer approve, and what reversible record proves the outcome?

Safety rule: No silent commit, duplicate retry, or ambiguous success.

Illustrative record: a safe handoff might carry variant_id, matched constraints, fitment evidence, market and company location, price and currency, availability, confirmation state, authority scope, expiry, and an idempotency key. These values are examples of the questions an implementation must answer, not a prescribed protocol.

Chapter 4 · Worked example

When the price changes, the action changes

Use an illustrative B2B part request: a buyer asks for a compatible filter, the search resolves one variant, and the buyer confirms the displayed price. Before cart commit, the market or catalogue context recalculates the offer. The safe agent does not treat the first response as permanent permission.

1. Discovery

Return one candidate with exact variant identity, compatibility evidence, buyer context, price, currency, and an explicit match state.

2. Confirmation

Show the buyer the item, variant, quantity, price, currency, and intended action. Record the confirmation, not merely the page view.

3. Revalidation

At cart or order boundary, check the same variant, context, availability, and current offer. If price changed, the old confirmation no longer covers the new amount.

4. Recovery

Tell the buyer what changed, present the new choice, and wait for fresh confirmation. Do not downgrade the difference to a formatting detail.

No silent substitution. A different variant, market, company location, currency, quantity, or price is a different action. It may be a valid new option, but it needs a new decision.

Chapter 5 · Failure and recovery

Every stop needs a reason and a next safe step

Agents fail unsafely when every problem is collapsed into retry. Give each failure a state that tells the agent whether to ask, stop, revalidate, or inspect the receipt. The state is part of the user experience and the operating evidence.

State	Meaning	Safe recovery
`partial`	A required dimension is missing or under-specified.	Ask one precise question and preserve the constraints already known.
`no_match`	No eligible item satisfies the hard constraints.	Stop, explain the boundary, or offer a clearly labelled alternative search job.
`price_changed`	The offer is different from the value the buyer saw or approved.	Show the new price and request a fresh confirmation.
`unavailable`	The selected item cannot be acted on under the current policy.	Do not substitute silently. Offer waitlist, backorder, or a new search only if supported.
`authorisation_missing`	The actor or scope cannot be verified for the requested action.	Stop and request the required sign-in, permission, or human step.
`duplicate_risk`	A retry may have committed the same action already.	Use an idempotent receipt or ask the merchant to inspect before retrying.

Chapter 6 · Platform boundary

Do not turn a framework into a native-support claim

Shopify's current B2B requirements documentation lists agentic storefronts as incompatible with B2B. That matters for the scope of this article: the safe-action model is a vendor-neutral way to structure questions and tests, not evidence that Shopify currently provides an end-to-end B2B agent checkout flow. Verify the platform and app boundary before promising an autonomous action.

Likewise, Shopify's Predictive Search API documentation describes a storefront discovery surface. A search response may provide products and variants for a storefront experience, but its presence does not grant authority to add to cart, place an order, or spend money. Discovery, action, and authorisation need separate evidence.

Boundary test: write down the exact platform surface, actor scope, action permission, confirmation event, and receipt your implementation supports. If one is unknown, label the flow as assisted or exploratory rather than autonomous.

Chapter 7 · Reader-run acceptance test

Test what the agent may do, not only what it can find

Use the following acceptance set before allowing a machine to move beyond discovery. Run it with an exact product, a compatibility case, a B2B context change, a volatile price or inventory state, and a retry.

Run a discovery query that returns an exact candidate. Confirm the response exposes match state, evidence, product identity, variant identity, price, availability, and context.

Change one hard constraint so the response becomes partial or no_match. Confirm the agent asks or stops rather than selecting the nearest result.

Change the market, company location, or customer context. Confirm the eligible assortment and price are re-evaluated rather than inherited from the first response.

Change the price or inventory between search and cart. Confirm the action pauses, explains the change, and obtains fresh confirmation.

Retry the same action after a simulated timeout. Confirm the receipt or idempotency check prevents a duplicate commit.

Remove action authority while leaving read authority intact. Confirm the agent can explain and recommend but cannot add, order, or pay.

Pass condition: the agent can explain a candidate without being able to commit, can commit only within explicit authority, and can recover from every stale, partial, unauthorised, or duplicate state without guessing.

Research basis

Keep the action claim smaller than the evidence

The framework extends the existing agent search and catalogue contracts with explicit action gates. Shopify documentation is used only for current search and B2B boundary checks. It does not establish a universal agent protocol, and it does not remove the need to verify the actual store, app, buyer, and cart behaviour.

Sources checked August 12, 2026

Agent Search Contract guide: The structured match states, variant identity, evidence, continuation, and authorisation fields used here.
Agent-Readable Catalogue guide: The catalogue identity, attribute, granularity, and freshness conditions that safe actions depend on.
B2B parts and compatibility guide: The fitment proof, negative case, and exact-variant handoff that precede any commercial action.
Shopify B2B Search Eligibility guide: The market, catalogue, customer, publication, inventory, and cart context that bounds an eligible result.
Shopify B2B requirements and considerations: Current platform boundary check. Shopify currently documents agentic storefronts as incompatible with B2B.
Shopify predictive search documentation: Reference for a storefront discovery surface. Discovery output is not, by itself, an order authorisation.

Final judgement

Safe agentic commerce is a permission system around a search system

The standard is not that an agent can find a plausible product. The standard is that it knows what it found, why it qualifies, who may act, what the buyer approved, what changed, and whether the commit happened. When the answer is uncertain, the safe action is visible recovery.