When AI Agents Become Buyers: What Changes in Commerce Infrastructure?

What happens when the person clicking ‘Buy’ disappears from the transaction? Is your e-commerce platform prepared for such a future? If not, this article discusses some essential points on how you, as an engineering leader, can ensure your commerce infrastructure works reliably when the buyer is a software.

Introduction: The buyer is changing

For years, this is what the customer journey has looked like-

The customer will search for a product, compare options, add one to a cart, enter payment details and click Buy.

AI shopping agents are changing that sequence.

A customer could tell an agent, “I need a new phone under $800. I want a good camera, and I’d like it to be delivered by this week.” The agent can search across merchant websites, evaluate products against the constraints, check availability and delivery, and potentially even complete the purchase.

The customer provides the intent and the agent handles much of the execution.

McKinsey expects agentic commerce to power up to $1 trillion in US retail sales and $3 trillion to $5 trillion worldwide, by 2030.

Are your systems changing too?

To be ready for this fundamental shift, the underlying infrastructure of merchant systems has to become capable of serving software as a customer interface.

That leads us to: what does a merchant actually need to expose for an AI agent to discover products, evaluate its options, and complete a purchase reliably?

Agents need access to accurate product data, real-time inventory, landed pricing, delivery estimates, substitution rules, and transaction state. They also need to interact with these systems without overwhelming APIs, bypassing security controls, or relying on outdated information.

Merchant systems need to go beyond making commerce accessible to agents. You need a robust commerce state that is machine-readable, reliably revalidated, and authoritative enough for agents to act on it.

Technical infrastructure know-how – How merchants should prepare

1. Make commerce data machine-readable and authoritative

A product description alone isn't enough for an agent to make a sound purchasing decision. It needs more information to determine whether a product meets the customer's needs, is available, and can actually be purchased.

That means exposing reliable interfaces for:

• Product - SKU, variant, attributes, specifications, compatibility
• Pricing - current price, promotions, taxes, shipping costs, other fees
• Inventory - SKU and location-level availability
• Fulfillment - delivery promises, pickup options, cutoff times
• Substitution - acceptable alternatives when the requested product is unavailable
• Transaction - cart, checkout, order, payment state

Merchants need to look at commerce data as a state with different consistency requirements, rather than as one uniform data set.

Not all commerce data needs the same level of consistency. Product descriptions, specifications, and category information can often be cached without much risk. Pricing, promotions, inventory, delivery availability, and checkout status are a different story. These need to be verified against the source of truth before a transaction goes through.

This is where an architectural distinction between read operations and transactional operations is useful.

Read operations can include:

• Search products
• Retrieve product or variant details
• Check availability
• Compare prices

Transactional operations might include:

• Create or modify a cart
• Apply a promotion
• Submit checkout
• Authorize payment
• Create or cancel an order

Each operation needs its own approach to caching, authorization, and retries.

For example, retrying a product search after a timeout is generally harmless. Retrying an order-creation request, however, could result in duplicate purchases unless the operation uses an idempotency key or a similar mechanism to prevent duplicates.

Different consistency / freshness requirements for several state domains can look like-

The goal is to make the merchant's underlying commerce state authoritative enough for agents to act on it.

2. Separate agent access from core commerce logic

There is already a growing ecosystem of protocols designed to connect agents, merchants, and payment systems. And their capabilities will continue to evolve.

Therefore, merchants should avoid rebuilding core commerce logic around whichever protocol is currently gaining adoption. Instead, external agent interfaces should sit on top of stable merchant-owned commerce contracts.

This is what a simplified architecture looks like:

1. AI agents / apps / websites
2. Protocol & access layer
   - Authentication
   - Agent identity
   - Authorization
   - Rate limiting
   - Quotas
   - Protocol adapters
   - Traffic monitoring
3. Merchant commerce APIs
   - Product discovery
   - Pricing- Inventory
   - Fulfillment
   - Cart
   - Checkout
   - Orders
   - Payments
4. Core commerce services
   - Catalog
   - Pricing
   - Inventory
   - Cart
   - Orders
   - Payments

The key is to keep the underlying systems consistent, regardless of how an agent accesses them.

An agent might connect through a structured API, a commerce protocol, or a browser, but it should ultimately interact with the same authoritative product, pricing, inventory, and transaction systems.

For example, Meta's Muse is a general-purpose personal agent with its own browser that can research products, navigate merchant websites and make purchases with user approval. OpenAI's dots similarly operates as a general-purpose agent with its own computer and can carry out tasks across connected environments.

Protocols should define how agents interact with a commerce system, not dictate how that system works behind the scenes.

3. Design for agent traffic

Agentic commerce also changes the traffic profile of a merchant's systems.

A human shopper might visit a handful of product pages before making a decision. An agent, on the other hand, can query hundreds of products, variants, prices, and fulfillment options in the same amount of time.

That makes it harder to differentiate legitimate, high-volume agent activity from malicious automation. Hence, a merchant's access layer should be able to establish:

• Who or what is making the request
• Which capabilities the requester is allowed to access
• How much traffic it is generating
• Whether the traffic is discovery or transaction-oriented
• When a request should be challenged or blocked

Rate limits and quotas should reflect what an agent is trying to do. A product search can tolerate high-volume read traffic from an authenticated agent identity, while an order-creation or checkout endpoint should have stricter controls.

This also changes how bot-management systems need to operate. Blocking all automation would prevent legitimate agents from accessing a merchant, while allowing unrestricted automation creates obvious abuse and infrastructure risks.

As a result, the goal should not simply be to ‘allow AI agents’. It should be to identify, authenticate, measure, and govern automated access.

4. Treat commerce content as untrusted input

There is also a new security consideration: prompt injection, i.e. the content the agent reads should not automatically become instructions the agent is allowed to follow.

You should treat product descriptions, reviews, seller-provided text, and other third-party content as untrusted input.

This becomes especially important when an agent also has access to privileged tools such as cart modification, checkout, or payment actions. A malicious product description could contain instructions meant to override the customer's original request. If the agent treats that content as trusted instructions, it could influence actions it was never supposed to take.

The architecture should maintain a clear boundary:Merchant content → untrusted data → agent reasoning → authorized tools

rather than:Merchant content → instructions → transaction

Transactional tools need explicit permissions and validation boundaries independent of the text an agent encounters while browsing.

Simply put, being able to read something shouldn't automatically give an agent permission to act on it.

5. Keep transaction state, authorization, and payments tightly connected

The final challenge is making sure an agent-initiated transaction can be tracked and audited from start to finish.

Merchants and payment providers need enough context to establish what happened at each stage: who initiated the transaction, which agent acted, what the customer authorized, and what was ultimately executed.

Consider a situation where an order is created successfully, but the response times out. The agent can't safely assume the order failed and submit the same request again. It needs a way to check the transaction's status before retrying.

For engineering teams, this means keeping cart, checkout, payment, and order systems connected rather than treating an agent-initiated payment as an isolated event. The system should be able to answer questions such as:

• What did the agent see when it made the decision?
• What price and inventory state did it receive?
• What did the customer authorize?
• Which actions did the agent perform?
• What order and payment events followed?
• Did the transaction fail, retry or execute more than once?

Consequently, transaction-changing operations need mechanisms such as:

• Idempotency keys: to make safe retries possible
• Optimistic concurrency/version checks: where state can change between reads and writes
• Inventory reservations: where the business requires temporary guarantees
• Explicit transaction states: clear statuses such as pending, confirmed, failed, or cancelled.
• Event reconciliation: across order, payment and fulfillment systems
• Observability and audit logs: a record of what happened at every stage of the transaction

Mastercard Agent Pay initiative focuses on making agent-led payments secure and seamless. It brings together agent identity, verifiable intent, and trusted execution to connect the user's authorization with the transaction the agent ultimately carries out.

The goal is to ensure that every transaction can be traced back to a legitimate agent and the user's original intent.

What changes for engineering teams

The fundamental change is that not everything needs to be changed. Merchants don’t need an entirely new AI stack.

You need to make your existing commerce systems more reliable at the points where software agents interact with them. That means-

• treating product information, pricing, inventory, and fulfillment as authoritative data rather than presentation-layer content.
• distinguishing cacheable discovery data from transaction data that must be revalidated.
• preparing access layers for higher volumes of legitimate automation.
• maintaining protection against abuse.
• making transaction state observable enough to establish what an agent was allowed to do and what it actually did.

This also explains why protocol-agnostic architecture matters.

It also means recognizing agent traffic as a distinct type of automated access. Blocking every agent as a bot isn't practical, but neither is giving all automated traffic unrestricted access.

Authentication, quotas, rate limits, authorization, and bot-management policies need to account for the difference between browsing products and performing high-impact actions such as placing orders or initiating payments.

Over time, merchants may need to support multiple agent ecosystems, commerce protocols, and browser-based agents. Building the core commerce system around a single one could create unnecessary dependencies as the ecosystem evolves.

A better approach is to expose stable commerce capabilities through an access layer while keeping the underlying systems independent.

Are you ready for commerce infrastructure 2.0?

The arrival of AI agents does not mean merchants need to predict which agent, protocol or interface will succeed. The more durable engineering priority is simpler: make the underlying commerce state reliable enough for software to act on it.

That's where companies like SoluteLabs can help: modernizing legacy systems, building API-first architectures, and integrating AI capabilities without simply bolting AI onto an otherwise unchanged technology stack.

Want to explore what this could look like for your business? You can reach out to us here.