Artificial Intelligence, Cross-Platform Topics

AI agents for ecommerce are software systems that hold authenticated credentials and call your order management system, ERP, and inventory APIs directly, then write changes back to those systems, placing a quote, updating an order line, or starting a return. A chatbot reads your content and produces an answer. A merchant agent holds permission and changes what actually happens in your systems.

Most ecommerce directors have already been sold a chatbot. It sits in the corner of the storefront, answers questions about shipping windows, and occasionally points a customer toward the returns policy page. It rarely gets credit for a sale, and it never gets blamed for one going wrong, because it cannot do anything that touches an order.

That is not a limitation of the model behind it. It is a limitation of what it was given permission to do. The distinction between a chatbot and a genuine agent has nothing to do with how convincing the conversation feels and everything to do with authority to act: does the system only read and respond, or can it authenticate, call a live system, and write a change back to it.

We build on Adobe Commerce, Magento Open Source, Shopify, and BigCommerce for manufacturers, distributors, and wholesalers, and we get asked to build “an AI agent” more often than we get asked to define one first. This post is the definition, the architecture, and the honest limits, written for the operations manager who has heard the pitch and wants to know what it would actually require.

What Are AI Agents for Ecommerce, and How Are They Different From Chatbots?

AI agents for ecommerce are distinguished from chatbots by one structural fact: they hold write access to backend systems, not just read access to a knowledge base. A chatbot is trained or prompted on your product content, policies, and FAQs, and it generates a response from that context. It has no session tied to a real customer account, no scoped credential to your order management system, and no path to change a price, a quantity, or a status.

A merchant agent is architected differently from the start. It authenticates as a specific customer or a specific service account, calls your product API, your ERP’s pricing endpoint, and your order system in real time, and then commits a change. That change is a write operation against a live database, not a generated sentence.

This is why the two categories cannot be evaluated on the same criteria. A chatbot’s quality is judged on how well it answers a question. A merchant agent’s quality is judged on whether the price it quoted was the contract price, whether the inventory it confirmed was actually on the shelf, and whether the order it placed matches what the customer meant.

A Chatbot Answers Questions, a Merchant Agent Completes Transactions

One way to see the gap is to put six common buyer requests side by side and ask what each system can actually do with them.

Capability	What a Chatbot Does	What a Merchant Agent Does
Price lookup	Quotes the list price from the content it was trained on	Calls the pricing API and returns the customer’s contract price
Stock check	Estimates based on static or cached product data	Queries live ERP inventory and returns a real-time count
Quote creation	Cannot generate one; refers the customer to sales	Builds a priced quote through the commerce and ERP APIs
Order change	Cannot modify an order; provides the support contact	Writes the change directly to the order management system
Return initiation	Explains the return policy in text	Validates eligibility and creates the RMA
Reorder	Suggests the customer browse the catalog again	Retrieves order history, re-prices it, and rebuilds the cart

A merchant agent completes the transaction because it is permitted to touch the systems where the transaction lives. That is a permissions and integration question, not a conversation-design question, and it is why calling a chatbot upgrade “an AI agent” without changing anything underneath it does not hold up.

A Merchant Agent Can Take 6 Actions That a Chatbot Cannot

Each of these actions touches a different system, and each needs its own guardrail, because a mistake here is not a bad answer, it is a wrong order.

1. Price lookup. The agent calls the ERP’s pricing endpoint (Epicor Prophet 21, NetSuite OneWorld, or SAP Business One all expose this differently) with the customer’s account ID. The guardrail is validating the customer segment before returning a number, because a session error here quietly returns catalog price instead of contract price.
2. Stock check. The agent queries live inventory rather than a cached catalog snapshot. The guardrail is a confidence threshold on data freshness; if the sync is more than a few minutes stale, the agent should say so rather than confirm availability it cannot verify.
3. Quote creation. The agent writes a quote object through the commerce platform’s cart API and the ERP’s quoting logic. The guardrail is a hard cap on discretionary discount, so the agent cannot generate a quote below an approved margin floor without escalating to a person.
4. Order line change. The agent writes directly to an existing order. The guardrail is a confirmation step before any write that touches a fulfilled or in-progress order, so the customer sees exactly what changes before it commits.
   
5. Return initiation. The agent checks a deterministic returns policy and creates the RMA. The guardrail is that the policy has to be rule-based; if a return decision still depends on a person’s judgment call, the agent will either approve returns it shouldn’t or block ones it should have allowed.
6. Reorder. The agent pulls order history, re-prices the line items, checks stock, and writes a new cart. The guardrail is duplicate-order detection, since a customer asking “did that go through” twice should not generate two shipments.

Why Do Ecommerce AI Agents Need Write Access to Your Order System?

Every one of those six actions depends on the same underlying requirement: ecommerce AI agents need write access, not read access, to the systems that hold price, stock, and order state. This is the part of the project that gets underestimated, because “write access” sounds like a checkbox and is actually a permissions architecture.

In practice, write access means a scoped OAuth 2.0 credential tied to a service account, not an admin login shared across integrations. It means defining exactly which endpoints that credential can call: order creation, yes; customer record deletion, no. It means every write is logged with a timestamp, the customer ID, and the agent session ID, so if something goes wrong, someone can trace it back to the exact call.

The integration itself usually runs through a middleware layer like Alumio, which sits between the storefront’s GraphQL or REST API and the ERP’s own API surface, translating and routing calls so ecommerce AI agents do not need a direct, brittle connection to Epicor Prophet 21 or Microsoft Dynamics 365 Business Central. For merchants running Magento Open Source or Adobe Commerce against one of those ERPs, this is the same integration layer that already handles order sync today, extended to accept writes initiated by an agent instead of only a person. We go deeper on this specific integration pattern in our post on Magento and Adobe Commerce ERP integration.

AI Agents for Post-Purchase Actions Handle Status, Reorders and Returns

If we had to pick one surface to start with, it would be post-purchase. AI agents for post-purchase actions carry lower risk than pre-purchase negotiation because the order already exists, the price is already set, and the agent is updating a known record rather than creating a new commitment from scratch.

Order status is the entry-level version: the agent authenticates the customer, calls the order management API, and returns real shipment data instead of a generic “check your email” response. Reorder is the next tier, retrieving a prior order, re-pricing it against current contract terms, and rebuilding the cart for confirmation. Return initiation closes the loop, validating eligibility against a deterministic policy and generating the RMA without a support ticket in between.

This sequencing is why AI agents for post-purchase actions fit B2B accounts especially well, where the same customer places repeat orders against a standing contract price.

How Does a Reorder Work Through Epicor Prophet 21?

A distributor’s customer sends the request: “Reorder the bearing kits from last month, same quantity.” Here is what a properly integrated agent does with that, in 6 steps.

1. Authenticate. The agent confirms the OAuth 2.0 session is bound to this specific customer account, not an anonymous visitor.
2. Retrieve order history. It calls the order history API and identifies the SKU and quantity from the prior order, 200 units of bearing kit B-7450.
3. Get the contract price. It calls the Epicor Prophet 21 pricing endpoint with the customer’s account ID and SKU. If this endpoint isn’t exposed, the agent silently falls back to catalog price, and the customer gets billed above their contract rate.
4. Check live inventory. It queries current stock in Epicor Prophet 21. If inventory sync runs on a nightly batch instead of real time, the agent may confirm 200 units that were sold to another account that morning.
5. Write to cart. It adds the line item at the confirmed contract price to the authenticated cart through the storefront’s API, then shows the customer a summary before committing anything.
6. Confirm and submit. Once the customer approves, the agent writes the order. If the service account’s write scope is misconfigured, this step fails, and the customer sees an error where they expected a confirmation.

Every failure point in that sequence is an integration gap, not a model limitation. This is the part of building AI agents for ecommerce that actually takes the time.

What Has to Be True in Your Stack Before AI Agents for Ecommerce Can Work?

Before any of the above is realistic, seven things have to be true in the stack. AI agents for ecommerce fail quietly and confidently when these aren’t in place, which is worse than not having one at all.

1. An addressable product API. GraphQL or REST access to your catalog, ideally with Schema.org Product markup and a search layer like Elasticsearch behind it, so the agent can find the right SKU reliably.
2. Real-time inventory. Not a nightly export. If the agent confirms stock, that number needs to reflect what’s actually on the shelf within minutes, not hours.
3. Customer-specific pricing exposed through an API. Contract tiers in Epicor Prophet 21, price lists in NetSuite OneWorld, or customer-specific catalogs in SAP Business One all need to be callable, not locked inside a report a person runs manually.
4. An authenticated session model. Every agent action needs to be tied to a real customer account through OAuth 2.0, never anonymous.
5. Order write permissions. A scoped service account with defined, limited write access, not shared admin credentials.
6. A deterministic returns policy. Rules a system can evaluate, not a discretionary call a salesperson makes case by case.
7. An audit log. Every write the agent makes needs a timestamp, a customer ID, and a session ID attached to it.

How Do We Scope and Deploy AI Agents for Ecommerce on Adobe Commerce and Shopify?

We start every engagement with the post-purchase surface, because it carries the prerequisites above without the added complexity of live pricing negotiation. On Adobe Commerce, that means the GraphQL Storefront API for reads, the REST API for order writes, and Alumio as the connector into whichever ERP holds inventory and pricing. On Shopify, it means the Admin API and the Order Editing API, with Shopify Flow handling some of the guardrail logic around confirmation steps.

For the agent’s own tool-calling layer, we build against the Model Context Protocol, which standardizes how the agent calls out to these APIs rather than requiring a custom integration for every tool. We also keep an eye on the Agentic Commerce Protocol and on platform-level moves like OpenAI Instant Checkout, both of which point toward a future where agents built outside your storefront may need to call into it directly. A pilot built on standard protocols today is far easier to extend into that ecosystem than one built on custom, one-off logic.

A typical pilot of AI agents for ecommerce, scoped to order status, reorder, and return initiation on one platform and one ERP connection, runs eight to twelve weeks. Most of that time goes to the integration and the guardrail logic, not the agent’s conversational layer.

When Should You Not Build a Merchant Agent Yet?

We would rather say this plainly than sell a project that will underperform. A merchant agent is the wrong purchase this year if any of these 3 conditions is true.

Pricing is still negotiated per order by a salesperson rather than pulled from a contract tier in your ERP. If there’s no API to call for the right number, the agent will guess, and it will guess confidently.

Inventory accuracy sits below roughly 95 percent. An agent that confirms stock based on unreliable data will oversell, and it will do it at whatever volume the agent operates at, not the occasional human error rate you’re used to managing.

Order writes still require a person to key changes into the ERP directly. If there’s no API endpoint for the agent to call, there’s no integration to build, and a chatbot that hands off to a human is genuinely the more reliable tool for now.

If any of these describe your operation, that’s not a reason to abandon the idea. It’s a reason to fix the underlying data and process first, since a merchant agent built on top of unreliable pricing or inventory data will fail faster and more visibly than the manual process it replaced.

Where Should You Start When Evaluating AI Agents for Ecommerce?

If you’re evaluating AI agents for ecommerce for your own operation, the first conversation shouldn’t be about the agent itself. It should be about your product API, your pricing structure, and how your ERP currently syncs inventory and orders with your storefront.

What we need to see before we can scope anything is straightforward: which platform you’re on (Adobe Commerce, Magento Open Source, Shopify, or BigCommerce), which ERP holds your pricing and inventory (Epicor Prophet 21, NetSuite OneWorld, Microsoft Dynamics 365 Business Central, or SAP Business One), and whether that ERP already exposes an API for pricing and stock or whether that’s part of the build.

From there, we can tell you honestly which of the seven prerequisites are already in place and which ones the pilot needs to cover first.

Support