An AI shopping assistant looks deceptively simple in a demo: connect a model, add product data, and render a chat box. Production changes the problem. The assistant must understand a merchant, operate safely on real carts and orders, remain useful across channels, and give a human enough evidence to diagnose what happened.
This article describes the architecture behind that transition without exposing merchant data or proprietary implementation details.
One agent, several interfaces
The system serves shoppers on storefront web chat, WhatsApp, and Instagram. Those channels share merchant knowledge and commerce capabilities, but they do not share the same interaction model.
Web chat can stream partial text, render product cards, and keep rich local UI state. Messaging platforms impose webhook lifecycles, delivery constraints, identity rules, and channel-specific media formats. Treating every channel as a thin transport layer creates brittle behavior.
The practical boundary is a shared agent runtime surrounded by channel adapters:
Channel event
-> identity and conversation resolution
-> normalized agent input
-> shared runtime and tools
-> structured response events
-> channel-specific rendering and deliveryThe runtime remains consistent while each adapter owns acknowledgements, retries, formatting, and platform semantics.
Knowledge is a product workflow
Retrieval quality starts before a shopper sends a message. Merchants need a reliable ingestion path for products, collections, policy pages, files, frequently asked questions, and brand guidance.
That pipeline needs observable states: queued, processing, indexed, failed, and stale. A document that silently failed to index is not a model problem; it is an operations problem.
Knowledge also needs provenance. Retrieved context should identify its source so the system can trace weak answers back to missing, stale, or contradictory material.
Tools define the agent's real authority
The model should not directly manipulate commerce state. It selects from typed tools that validate inputs and enforce policy. Typical capabilities include product discovery, variant lookup, cart operations, order status, and handoff to a person.
A tool contract should communicate more than arguments:
type ToolResult<T> = {
ok: boolean;
data?: T;
userMessage?: string;
retryable?: boolean;
audit?: Record<string, string>;
};This gives the runtime enough information to recover from transient failures without inventing success. Risky actions require stricter confirmation than read-only searches, and every mutation remains attributable to a conversation and tool execution.
Memory needs boundaries
Conversation history is useful, but unlimited history is expensive and noisy. The runtime separates recent conversational context from durable shopper or merchant facts. Durable memory must be explicit, inspectable, and removable.
Cross-channel memory adds another constraint: identity resolution. A website visitor and a WhatsApp contact should not be merged simply because the content looks similar. The system only connects identities through defensible platform or merchant workflows.
Human handoff is part of the architecture
Handoff cannot be an apologetic final sentence. It is a state transition. Once triggered, the system records the reason, preserves the relevant transcript and tool context, alerts the correct queue, and changes how automated replies behave.
Good handoff triggers include explicit shopper requests, repeated tool failures, policy-sensitive questions, and low-confidence situations where guessing would be costly.
Observability closes the loop
Production agent debugging requires a trace across retrieval, model calls, tools, latency, token usage, delivery, and final outcome. A transcript alone cannot explain why the assistant chose an irrelevant product or repeated an action.
Traces should answer:
- Which knowledge sources were retrieved?
- Which prompt and configuration were active?
- Which tools were selected and what did they return?
- Where was time spent?
- Did a channel retry or duplicate an event?
- Was a human eventually involved?
The useful unit is the complete shopper turn, not an isolated model request.
What made it production-ready
The largest improvements did not come from repeatedly changing the model. They came from strengthening the system around it: deterministic tool contracts, reliable ingestion, channel-aware delivery, explicit state transitions, traceability, and merchant controls.
An agent survives production when failure is visible, authority is bounded, and operators can understand what it did. The model matters. The surrounding product and operational architecture matters more.