The model knows the world.
The system knows your store.

How the orchestrator routes catalog, orders and human handoff in one session. World knowledge can answer a product question. Commerce requires catalog, inventory, fitment, policy and order data, with the right context carried across every change in intent.

A shopper asks for a red jacket in size medium. A general-purpose LLM gives them a fluent answer in seconds. It can summarize reviews, compare common features and explain what a technical fabric rating means.

Then the shopper reaches the store.

That's one shopping session. It contains several jobs.

The first question can draw on broad knowledge. The next questions require catalog truth, variant-level inventory, shipping policy, account access, order data and a support workflow. A model can produce fluent language for any of these. What decides whether the language is reliable is the layer of systems the model is answering from.

That's the difference between a chat layer and commerce AI built for a merchant's workload.

Webscale's AI Shopping Assistant works across the merchant's catalog, inventory, fitment rules, policies, order data and support workflows. An orchestrator routes each turn to the right specialist while the shopper's context stays with the session. General knowledge can fill a gap. Merchant data remains authoritative when the two conflict.

The assistant is a team of specialized agents behind an orchestrator. Product discovery reads from the catalog and inventory. Order history and shipping status are handled by a separate agent. Returns, account questions and the path to a human support agent belong to a third. And when the merchant's own data doesn't reach a question, a fourth agent fills in with general world knowledge.

The orchestrator decides which specialist should handle each turn. It also carries the session forward when the shopper changes subjects.

That matters because shoppers don't follow the boundaries in a system diagram. They can move from compatibility to stock to an existing order in three messages. If each change starts a new conversation, the experience becomes a collection of disconnected bots. If one model receives every tool and every policy in one prompt, the model has to sort through unrelated contexts and may use the wrong source.

Giving each agent a narrower job with its own data boundary is what makes the specialization work. The orchestration on top of it is what makes the whole thing feel like one conversation to the shopper.

General-purpose LLMs already know a great deal about the world. They can explain what an industry term means and how a brand's reputation has shifted over time. When a category standard needs interpreting, they can do that too. That's useful context, and the AI Shopping Assistant can use it.

The harder part is bringing that context into a response that also respects what the merchant knows.

Suppose outside information says a product is commonly available in a shopper's state. The merchant's shipping rules say that SKU can't go there. The merchant's rule controls the response. Suppose reviewers say an accessory usually works with a product family, while the merchant's fitment matrix excludes the exact variant in the shopper's cart. The fitment matrix controls the recommendation.

Store-aware assistance works at the level where commerce decisions happen.

Catalog data keeps recommendations inside the assortment and ties claims to the right product or variant. Inventory prevents the assistant from steering a shopper toward an unavailable SKU. Fitment and compatibility rules resolve details a general model may never have seen. Policy data governs restrictions, disclaimers and shipping eligibility. Order and account data make post-purchase questions answerable. Session context keeps all of those turns connected.

For a low-consideration purchase, a plausible answer may lead to a return. In auto parts, archery, age-gated categories, supplements or other regulated and high-consideration commerce, it can create a safety or compliance problem. Fluency alone will not catch either failure mode. What catches it is the data layer sitting underneath the model.

Human handoff is part of the architecture, not an escape hatch at the edge of it.

When a shopper asks for help from a person, the session can move with them. The support agent receives the conversation context instead of asking the shopper to explain the problem again. The handoff preserves the path that led there, including the products considered, the questions asked and the point where the AI stopped.

For developers, this turns handoff into a state problem. A conversation has to have a durable identity so it can survive a change of handler. The context attached to it has to travel with the shopper, without the receiving system inheriting data it should never see. When any part of that fails, the shopper is the first to notice, because they end up having to start over.

That engineering is part of the product experience. The shopper only notices when it's missing.

Product discovery is the easy demo. Use a sequence that forces the system to cross boundaries.

A good first answer is easy. What matters is what the system does with every turn after it, once the conversation has changed shape into something the model on its own can't handle.

A storefront conversation that can query merchant systems, use general knowledge, switch specialists and hand the session to a person without dropping context.