AI agents are moving from answering questions to completing tasks, and commerce is one of the first places where that shift has a measurable commercial consequence. Instead of a customer browsing a site, an agent acting for that customer discovers products, compares them, and in some cases completes a checkout.
That changes what a commerce platform is asked to do. Success no longer depends only on the quality of the storefront. It depends on whether the product data is machine-readable, whether the checkout can be invoked by software, whether inventory and pricing are accurate in real time, and whether a transaction can be attributed to a person who authorised it.
This article sets out what agentic commerce actually means today, the technology a business must build, and where the capability genuinely exists versus where it is still being specified. Our related guide to MCP and A2A in enterprise integration covers the underlying connection layer in more depth.
What agentic commerce means
Agentic commerce is commerce in which an AI system performs part or all of the buying process on a person's behalf, within limits that person has set. The agent may research, shortlist, negotiate, or complete a purchase. The buyer remains the buyer; the agent is an instrument acting on their instructions.
The distinction that matters commercially is between an agent that recommends and an agent that transacts. Recommendation is widely deployed. Transaction from an AI interface is emerging, is governed by new protocols, and is typically limited to participating merchants and approved categories.
How agents differ from traditional e-commerce automation
Rule-based automation executes a defined path. An agent interprets an intent and decides which path to take.
| Capability | Rule-based automation | AI assistant (conversational) | Agent that executes |
|---|---|---|---|
| Input | Fixed fields and triggers | Natural language | Natural language plus constraints and goals |
| Comparison | Predefined rules | Explains options | Evaluates options against criteria and decides |
| Action | Adds to cart, sends email | Suggests a link | Initiates checkout, submits an order, tracks fulfilment |
| Error handling | Fails to a queue | Asks a clarifying question | Retries, substitutes within constraints, escalates to a human |
| Control | Deterministic | Advisory | Requires explicit authorisation, limits and audit trail |
The fourth row is where most programmes fail. An agent that cannot recover from a declined card, an out-of-stock item or a partial shipment without a person is not an operational system.
What agents need from product data
An agent can only buy what it can read. Catalogue quality moves from a merchandising concern to a functional requirement.
| Data requirement | Why it matters to an agent | Practical implementation |
|---|---|---|
| Stable identifiers | Prevents matching the wrong product or variant | GTIN, MPN and SKU, exposed consistently |
| Structured attributes | Enables comparison across brands and models | Structured product markup such as schema.org Product and Offer |
| Availability and lead time | Avoids promising what cannot be shipped | Real-time stock service, not a nightly file |
| Price and conditions | Prevents completing a purchase at a stale price | Price service with timestamps and validity |
| Shipping and returns terms | Determines whether the purchase is acceptable | Machine-readable policy fields per product and destination |
| Condition and provenance | Essential for graded, refurbished and recommerce stock | Grading standard, serial or IMEI, warranty status |
The last row is where most electronics and recommerce catalogues fall short. A listing that says "good condition" is not a specification. An agent acting for a business buyer needs grade, battery health, cosmetic defects, accessories included and warranty terms as distinct fields before it can make a defensible decision.
How an AI-initiated purchase actually runs
The flow is recognisable, but the responsibility boundaries are new.
- The buyer states an intent and constraints: category, budget, quantity, required attributes, delivery deadline.
- The agent discovers candidate products, either through a merchant's feed, a marketplace API or a protocol-specific endpoint.
- It compares options against the constraints and produces a shortlist, with reasons.
- It initiates a checkout session with a chosen merchant, passing the items and quantities.
- Payment is handled through a tokenised mechanism, so the agent never holds raw card credentials.
- The merchant creates the order as merchant of record, applies its own rules on which products may be sold to agents, and fulfils.
- Post-purchase events, including cancellation, returns and exceptions, are routed back to the buyer or agent.
Steps four and five are where standards now exist. Discovery, comparison and post-purchase handling remain largely implementation-specific, which is exactly where the engineering effort sits.
The protocols and their current status
| Protocol | Governance | What it standardises | Status at the time of writing |
|---|---|---|---|
| Agentic Commerce Protocol (ACP) | Open source under Apache 2.0, developed by OpenAI and Stripe | Agent-to-business checkout: product feed, checkout session, secure payment token handoff | Implemented by ChatGPT, with Stripe as the first compatible payment provider; merchants apply per platform rather than being listed automatically |
| Agent Payments Protocol (AP2) | Open protocol originated by Google; standardisation continuing within FIDO Alliance working groups; version 0.2 | Verifiable intent for agent payments through signed mandates covering checkout and payment | Published specification with reference implementations, available as an extension for A2A and with a published UCP integration guide |
| Model Context Protocol (MCP) | Open standard with broad client and server support | How a model accesses tools, data and resources | Widely supported across AI clients, servers and developer tools; specification revisions are dated |
| Agent2Agent (A2A) | Linux Foundation, maintained by a technical steering committee | Agent-to-agent discovery, task delegation and result exchange | Apache 2.0, with SDKs published in several languages |
| Universal Commerce Protocol (UCP) | Open, community-developed | Commerce capabilities with a documented AP2 integration path | Documentation published; ecosystem in formation |
Two notes on accuracy. First, these are live specifications, and details change between revisions; check the primary documentation at agenticcommerce.dev, ap2-protocol.org, modelcontextprotocol.io and a2a-protocol.org before building against a specific version. Second, protocol availability is not market adoption. Participation is per-platform and per-merchant, and agent-initiated checkout is not yet a mainstream channel in most categories.
Where agentic commerce applies commercially
B2B marketplaces
An agent representing a facilities company can assemble a basket across approved suppliers, check contract pricing, confirm stock and place orders within an approved limit. The value is real because the work is repetitive, the catalogue is structured, and the authorisation model maps onto existing procurement rules.
Consumer electronics and recommerce
Agents are well suited to specification-heavy comparison, and to procurement of graded stock where the required fields can be structured. The commercial opportunity for recommerce operators is to make condition data machine-readable, which improves both agent commerce and human conversion.
Enterprise procurement and replenishment
The strongest near-term use is not open-ended shopping but constrained replenishment: reordering known items within a pre-approved contract, with an approval step above a value threshold.
Product verification and data accuracy
An agent's accuracy is bounded by the truth of the data it reads. Where catalogues are maintained by hand, inconsistencies reach the transaction.
Practical controls: validate identifiers on ingestion, reject listings missing mandatory attributes for their category, timestamp price and stock, record which source supplied each field, and reconcile against the physical system of record. For graded electronics, treat verification as a workflow with evidence attached rather than a free-text field.
APIs, inventory and payment integrations
An agent-ready platform needs four things to be genuinely operable: a catalogue API with structured attributes, a real-time availability service, a checkout API that can be invoked by a third party, and a payment path that issues tokens rather than exposing credentials.
Inventory is the usual weak point. Cached stock figures produce orders that cannot be fulfilled, and the cost of that failure lands on the merchant's service desk. Where an agent can transact, availability must be read from the same source as the warehouse, with reservation at checkout and a defined behaviour when the reservation fails.
Payments are the area where the protocols have moved fastest. ACP's shared payment token model separates the credential from the agent, and AP2's approach uses signed mandates to establish that the user authorised the specific checkout. Both exist to prevent an agent from being treated as an untrusted party holding card details, and neither removes the merchant's own obligations under card scheme rules. Our API and systems integration work covers the connecting layer in practice.
Identity, authorisation and transaction security
Three questions must be answerable for every agent transaction: which human authorised it, what limits applied, and what evidence exists afterwards.
Answering them requires delegated authorisation with scoped, time-bounded credentials; explicit limits by value, category and frequency; separation between the agent's identity and the user's; and an audit record that links the human instruction to the order. Where a purchase carries commercial or legal consequence, a human approval step belongs in the flow. No responsible implementation allows an agent unrestricted discretion over spending.
What enterprise architecture must look like
- A catalogue and pricing service that is authoritative, versioned and queryable
- An availability and reservation service with defined failure behaviour
- A checkout service designed for machine invocation, not only browser sessions
- A payment abstraction that supports tokenised credentials and merchant-of-record obligations
- An identity layer supporting delegated access and per-agent credentials
- An event stream for order, cancellation and fulfilment events
- Logging and attribution that reconstruct any agent-initiated transaction end to end
Most of this is the same infrastructure a well-built commerce platform needs for its own channels. Agent readiness is therefore less a new system than a discipline of exposing what already exists in a machine-usable form.
Preparing an existing commerce platform
- Audit the catalogue against the attributes an agent needs for your main categories.
- Remove free-text fields from decision-critical data, starting with condition, warranty and compatibility.
- Confirm that stock and price can be read in real time by an external caller.
- Expose a checkout path via API, with clear rules on which products and destinations are eligible.
- Define a delegated authorisation model with limits before any agent is connected.
- Instrument the funnel so agent traffic is distinguishable from human traffic.
- Review the returns and exception handling path, because agent orders fail in the same ways human ones do.
Implementation roadmap
| Phase | Objective | Complete when |
|---|---|---|
| 1. Data readiness | Structured, validated catalogue for the target categories | Mandatory attributes present and reconciled with the system of record |
| 2. Interface readiness | Real-time availability, pricing and checkout APIs | An external caller can complete a test order end to end |
| 3. Authorisation | Delegated identity, limits and approval thresholds | Every agent action is attributable and bounded |
| 4. Protocol participation | Implement the chosen specification, or a merchant feed where required | A pilot agent completes a real transaction in a controlled category |
| 5. Operations | Monitoring, exception handling, returns and reconciliation | Agent orders handled by existing support without escalation |
Commercial opportunities and limitations
The opportunity is access to buying that begins inside an AI interface, and a defensible advantage for whoever makes their catalogue usable first. It also raises the value of data quality, since poor product data becomes a direct loss of sales rather than a merchandising nuisance.
The limitations are just as real. Buyer trust in autonomous purchasing is developing. Participation is granted per platform rather than automatically. Liability for a wrong purchase remains contested across merchant, agent operator and payment provider. Compliance obligations for the merchant do not transfer to the agent. And for low-volume, high-consideration purchases, a person still wants to be in the loop.
We set out the wider organisational view of where agent automation pays back in our guide to AI agents for business, and the ecosystem-level failure modes in why ecosystem platforms fail at the second participant.
How Sardo Group supports agent-ready commerce
Our work in this area sits in four parts: structuring the catalogue and integration layer so a machine can transact accurately; building the checkout, authorisation and event plumbing; integrating payment and logistics providers; and designing the operational controls that make agent traffic safe to accept. Where several organisations are involved, the architecture questions are ecosystem questions, which is the focus of our ecosystem development practice.
Frequently asked questions
What is agentic commerce in simple terms?
It is commerce where an AI agent performs part of the buying process for a person, within limits that person has authorised. Early deployments concentrate on research and comparison, with transaction capability expanding where platforms and merchants support it.
Which protocol should a merchant implement first?
None by default. Start with structured product data and a machine-invocable checkout, because those are useful regardless of protocol. Then implement the specification required by the platform you actually intend to sell through, having read its current documentation.
Can AI agents make purchases without human approval?
They can be authorised to, within limits. A responsible design sets value ceilings, category restrictions and frequency caps, and requires human approval above a threshold or for unusual purchases. Unrestricted spending authority is not a defensible design.
Does agentic commerce replace our storefront?
No. It adds a channel. The same catalogue, inventory and payment obligations serve both, and the work of making data structured improves the human experience as well.
What does it cost to become agent-ready?
It depends on the state of the catalogue and whether checkout already exists as an API. Businesses with structured product data and a headless commerce stack are largely connecting and hardening. Businesses with hand-maintained catalogues face data remediation first, which is the larger cost.
Is agentic commerce relevant to B2B, or only retail?
It is often more relevant to B2B, because purchasing is already delegated, rule-bound and repetitive. Contract pricing, approval limits and replenishment are natural fits for a constrained agent.
Build Your Agentic Commerce Platform
If you are assessing whether your commerce platform can accept agent-initiated transactions, the useful first step is an honest audit of catalogue structure, checkout APIs and authorisation. We can run that audit and build what follows. Start with AI and automation, look at API and systems integration, marketplace development and ecosystem development, or start your agentic commerce project and we will map the work against your current stack.