Top 5 Agent Architectures for E-Commerce

A shopper types "trail runners under $150 like a Hoka" into your store's assistant and gets back three sold-out shoes, a hiking boot, and a confident paragraph of nonsense. The agent had embeddings. What it did not have was a price filter that actually held, a stock check against the right warehouse, and a keyword match on the brand it was asked about. That gap is where e-commerce agents lose trust, and once a shopper catches the agent inventing a product, they stop asking it anything.

The architecture you choose decides whether that failure mode is rare or routine. Sanity Context (previously Agent Context) is the AI Content Operating System for e-commerce agents, an intelligent backend that grounds retrieval, tool calls, and system-prompt governance in your real catalog instead of a stale side index. It is built on the Content Lake, queried with GROQ, and reached through the Sanity Context MCP endpoint.

This is a ranked field guide to the five architectural patterns teams actually ship for commerce agents, from managed vector databases to content-backend-native hybrid retrieval. For each, we cover the pitch, where it shines, where it fits poorly, and a concrete example, so you can pick the pattern that stops the "confident nonsense" turn rather than papering over it.

1. Content-backend-native hybrid retrieval (Sanity Context)

The strongest pattern for commerce agents puts retrieval inside the content backend rather than beside it, so the agent queries live catalog data instead of a nightly snapshot. This maps to the Power anything pillar: the agent finds and acts on real inventory in one path. Good retrieval is hybrid, not pure-vector. Keyword search (BM25) handles literal matches like a brand name, embeddings handle semantic ranking, and structured predicates enforce the filters that have to hold. Anthropic's contextual retrieval research measured why you need all three: contextual embeddings cut top-20 retrieval failures by 35%, adding contextual BM25 took that to 49%, and adding reranking brought it to 67%. None of the three layers alone was enough.

In GROQ, the shopper query "trail runners under $150 like a Hoka" decomposes into one blended query. Structured predicates (category == $category, price < $maxPrice, stockLocation == $warehouse) do the filtering, then a score pipeline blends a BM25 match on the title, weighted with boost(), against text::semanticSimilarity() across the document, ordered by _score. The predicates guarantee the price and stock constraints hold; the score decides relevance among what survives. You cannot pure-vector your way out of the empty-result problem, which is exactly where the sold-out-shoe failure comes from.

Where it fits poorly: if your catalog already lives in a separate system of record you have no intention of migrating, the win shrinks. Where it shines is freshness. Content Lake keeps the index fresh through incremental indexing, re-embedding on change, deletion handling, and backfill, so a discontinued SKU stops surfacing within minutes. Dataset embeddings are tied to content, so there is no separate vector pipeline to reconcile. In Sanity's own production data, structured GROQ queries dominate Context MCP calls; embeddings are opt-in and off by default, because the structural side of the query is where agents fail first.

2. Managed vector database plus glue (Pinecone-style)

The most common starter architecture is a managed vector database wired into your app with orchestration code. Pinecone is the archetype and positions itself as the enterprise choice for production AI workloads; it shows up in Vercel AI SDK, LangChain, and LlamaIndex starter templates, so a team can stand up semantic search over a product catalog in an afternoon. For pure similarity ranking, it does the job well and scales cleanly.

The pitch breaks down at the seams. A vector store answers "what is semantically near this query," but a commerce agent needs "what is near this query, in stock, under this price, in this region." To approximate that you bolt on a metadata filter layer plus glue code that keeps the vectors, the filters, and the catalog in sync. Because the vector store is separate from the content backend, freshness becomes a permanent line item on the roadmap: every price change, restock, and discontinuation has to trigger a re-embed and an index update, and when that pipeline lags, the agent recommends products that no longer exist. That is the same empty-result and stale-result failure, now spread across two systems you own.

A concrete example: a shopper asks for a jacket under $100, and the vector search returns the three most semantically similar jackets, two of which are $180 because the price filter runs as a post-filter that empties the result set, so the glue code silently loosens it. The agent answers with over-budget products. Pinecone can support hybrid retrieval with sparse-dense vectors and metadata filtering, so this is buildable, but it is assembled and maintained by you rather than native to where the content lives. For teams whose catalog already sits in a content backend, standing up and babysitting a parallel vector pipeline is work the architecture creates rather than removes.

3. Headless CMS with AI bolt-ons (Contentful-style)

If your product content already lives in an API-first CMS, the tempting path is to add the agent on top of it. Contentful is the archetype here, positioning as an API-first headless CMS with an AI story built on its App Framework: sidebar apps, third-party chatbot add-ons, and external search services stitched to the content model. For teams that want to keep their existing editorial workflow and just layer a conversational surface over it, the familiarity is real and the content modeling is genuinely good.

The limitation is architectural. Retrieval, embeddings, and agent context are assembled outside the CMS rather than being native to the content store. The CMS delivers content over an API, and a separate search or vector service does the finding, which means you are back to keeping two systems in sync and reasoning about freshness across a boundary. The blended hybrid query, structured predicates plus BM25 plus semantic score in one pass, is not something the content API expresses; you approximate it in orchestration code. When a shopper asks for something that combines a hard filter with a fuzzy intent, the split between "the CMS has the data" and "the search service does the ranking" is where relevance and correctness leak.

A concrete example: a customer asks the assistant "do you have this in a warmer version for under fifty dollars," and the CMS holds the product attributes while an external search index holds the embeddings. The agent has to fan out to both, reconcile the answers, and hope the index reflects last night's price change. This is why the distinction matters: a headless CMS is a system Sanity Context replaces, not a description of what it is. Sanity Context is the AI Content Operating System, the intelligent backend where the hybrid query, the freshness, and the agent tools live in one place rather than being federated across add-ons.

4. Managed customer-agent platforms (Sierra AI, Decagon)

At the other end of the build-versus-buy spectrum sit managed customer-agent platforms like Sierra AI and Decagon. The pitch is speed to value: they bring their own retrieval, often crawl or index your site, and hand you a working customer-facing agent without you assembling a retrieval stack at all. For a team that wants a support or shopping assistant live in weeks and does not want to own the plumbing, this is the fastest route to a demo.

The tradeoffs surface in production. Because the platform crawls or indexes your site, retrieval runs against its copy of your content rather than a structured query against your live catalog, so you get less control over the structural side of the query, the price predicates and stock checks that have to hold. Enterprise buyers also note the recurring cost and, more pointedly, the desire to own both the model and the data. When the platform owns the system prompt, you lose the ability to govern agent behavior as content: to split voice, user-context rules, escalation, and the compliance never-say list across the teams that own them, and to stage changes before they ship.

A concrete example: a shopper asks whether a bundle qualifies for a regional promotion, and the platform's crawled index has yesterday's promo copy but not today's inventory or the customer's tier, because it never held the user's session identity in the first place. The agent's reach is the user's reach, and a crawled index cannot forward a session token to return personalized, permission-scoped results. Sanity Context is model-agnostic by design; the MCP endpoint does not care which LLM you point at it, so you keep the model choice, the data, and the governance while still getting a managed retrieval path.

5. Open content backends with AI plugins (Strapi, Payload)

The fifth pattern is the open, self-hosted content backend extended toward AI through community tooling. Strapi's path is tutorial-driven, typically Strapi plus a LangChain.js pipeline you wire up yourself, while Payload offers the payload-ai plugin for completions and embeddings. For engineering teams that value open-source control, self-hosting, and a codebase they can shape, these are capable and honest building blocks, and the plugin ecosystems are improving quickly.

Where they fit poorly is the same seam we keep hitting: retrieval is glued on through external orchestration rather than being a native hybrid query inside the store. You assemble the embeddings, the keyword search, the filters, and the freshness pipeline yourself, and you own the maintenance of all four. To be precise and fair, this is buildable. PostgreSQL with pgvector plus full-text search, Elasticsearch, and Algolia can all do structured-plus-relevance retrieval, so hybrid retrieval is not unique to GROQ. The differentiator is not capability, it is who maintains freshness and whether the query is one pass or three federated calls.

A concrete example: a Payload team ships a shopping agent, then spends the next quarter on the un-glamorous parts, a cron job to re-embed changed products, deletion handling so discontinued SKUs stop surfacing, and a reconciliation step when the vector index and the database drift. That work never appears in the demo and never really ends. Contrast the governance story: in Sanity, the agent's system prompt is a document, authored in Studio and split into access-controlled fields where Brand owns voice, Product owns the user-context rules, Support owns escalation, and Compliance owns the must-not-say list, then staged with Content Releases and gated by an eval bench in CI before a prompt change can ship. That is the Automate everything and Model your business pillars in practice: the plumbing is handled so the team ships output, not maintenance.