Most conversations about AI agents in ecommerce are conversations about models. Which one is smartest, which one writes the best copy, which one your competitor announced last week.

That is the least interesting part. The model is a commodity you rent by the token. What decides whether an agent does anything useful for your business is far duller and entirely within your control: whether your systems can be asked a question and give a straight answer.

What is an AI agent in an ecommerce context?

An agent is software that decides what to do next rather than following a fixed path. Given a goal, it works out which steps to take, calls the systems it needs, and reacts to what comes back.

A script checks stock at nine every morning and emails a report. An agent notices a supplier delay, checks what is affected, works out which orders are at risk and drafts the customer notices for someone to approve. The difference is not intelligence. It is that the second one had to look things up mid-task, and got answers.

Why AI agents fail on monolithic ecommerce platforms

Agents fail in production for reasons that have nothing to do with the model. They fail because the agent asked a question and the stack could not answer it.

On a monolithic platform, your data is available in the shapes the vendor decided to expose. Usually that means a page for a human to read, a nightly export, or an API that covers the common cases and nothing else. An agent trying to answer whether this specific customer can still change this specific order finds no way to ask. So it guesses, and a confident guess is worse than no answer at all.

The second failure is permissions. Anything touching a real customer needs to know what it is allowed to see and do. Systems built for humans clicking through screens rarely express that in a way software can respect, so you end up choosing between an agent that can do nothing and one you cannot safely let near production.

What composable commerce gives an AI agent that a monolith cannot

A composable stack is one where each capability is a separate service reachable by API. That structure was not designed with agents in mind, but it happens to be exactly what they need.

• Every capability is addressable. Catalog, orders, content, search and fulfilment can each be queried directly rather than scraped out of a page
• Answers arrive now, not overnight. An agent deciding something at 2pm cannot work from last night's export
• Permissions are explicit. API level scopes mean you can grant an agent read access to orders and nothing else, and prove it
• Each part can change alone. Swapping search or content does not mean rebuilding checkout, so the stack can evolve at the pace the work needs

Platforms like Commerce Layer are built this way from the start. So is a Shopify build where the storefront is decoupled and the commerce layer is reached through its API.

Why headless content matters for AI agents

The part teams underestimate is content. An agent asked to assemble a landing page, answer a product question or localize a campaign needs content as structured pieces, not as finished pages.

If your product care instructions exist only inside a rich text blob on one template, an agent cannot reuse them. If they exist as a field, they can appear in a support answer, a product page and an email without anyone rewriting them. This is the same argument for structured content that existed before agents. Agents just make ignoring it more expensive.

A headless CMS such as Sanity or Storyblok gives you that structure. Pair it with a vector database like Pinecone and an agent can retrieve by meaning rather than by exact match, which is the difference between finding your returns policy and finding nothing because the customer said refund.

Where AI agents actually earn their keep in mid-market commerce

The useful work is unglamorous and internal. In our experience the returns come from four places.

• Support triage. Reading, categorizing and drafting responses, with a human approving anything that reaches a customer. Models from Anthropic and OpenAI both handle this well
• Catalog quality. Finding products with thin copy, missing attributes or images that contradict the description, across a catalog nobody has time to audit
• Operational exceptions. Orders stuck between systems, stock that does not reconcile, syncs that failed quietly. Pairing an agent with workflow automation like n8n turns a weekly manual check into something that surfaces itself
• Search relevance. Improving what shoppers find, measured against real queries rather than a demo. This sits alongside a search platform like Algolia rather than replacing it

This is the thinking behind Compass Commerce, the AI operating engine we built for this exact problem. It connects the systems a mid-market brand already runs, then lets agents work across them with permissions and governance in place from the start. It came out of the same observation this article started with: the model was never the hard part.

Notice what is not on that list. Customer facing chat is the most visible use of AI in commerce and usually the least valuable, because most questions people ask a bot are questions a better product page would have answered.

Keeping agents reviewable, not just clever

An agent that can act on orders deserves the same scrutiny as a checkout change. Most do not get it, because they are assembled in a dashboard where nobody can see what changed or roll it back.

This is why frameworks like Vercel Eve matter more than they first appear. Defining an agent as code puts it in version control and through the same review and deploy path as everything else you ship. That is a governance argument rather than a technical one, and it is the argument that gets an agent past a cautious finance director.

When you should not build AI agents into your stack

Plenty of the time, you should not.

• If the underlying process is undocumented, automating it encodes the confusion rather than removing it
• If nobody will own the outputs, quality drifts and nobody notices until a customer does
• If the real problem is merchandising, content or acquisition, an agent will consume the budget that would have fixed it
• If your data is inconsistent, an agent will surface that inconsistency at speed and with confidence

The honest sequence is to fix the data and the architecture first. Agents amplify whatever they are pointed at, including a mess.

How to tell whether your architecture is agent ready

Three questions, answerable without a consultant.

• Can something other than your website ask your commerce platform a question and get an answer in a second?
• Is your content stored as structured fields, or as finished pages?
• Could you give a piece of software read access to orders and nothing else, and prove that is all it can do?

Three yeses and you can start on the use case. A no anywhere and that gap is the project, not the agent.

Common questions

Do we need composable commerce to use AI at all?

No. Content generation and catalog work can run against exports on almost any platform. What needs composable architecture is anything acting on live data, because that requires real time access and real permissions.

Is this only realistic for enterprise brands?

No, and the mid-market often moves faster because the decision path is shorter. What matters is whether your systems are addressable, not how large you are. A mid-market brand on a decoupled Shopify build is better placed than a large one on an old monolith.

Which model should we use?

Whichever fits the job, and design the build so you can change your mind. Keep prompts, retrieval and evaluation separate from the model call. Anything that hardcodes one provider throughout is a decision you will regret inside a year.

How do we stop an agent from making things up?

Give it your data to work from rather than its own memory, constrain what it may decide alone, and evaluate against real examples before launch. Most of the safety comes from scope, not from clever prompting.

Where should we start?

With one contained internal job that has a clear boundary and a human check. Support triage or catalog auditing are good first candidates. Anything touching money or inventory comes later, once you trust the pattern.

The short version

Buying a smarter model will not make an agent useful if your systems cannot answer its questions. The work that makes AI pay off in commerce is the architectural work you would benefit from anyway: structured content, addressable services, real permissions and clean data.

If you want a straight read on whether your stack could support this, or whether it is worth doing at all, that is a conversation about your specific systems rather than a platform demo. See the platforms and vendors we build with, or take a look at Compass Commerce, the AI operating engine we built to do this work across a commerce stack without the integration project first.