D2C BEAUTY / CONVERSATIONAL COMMERCEFrom product questions to connected commerce.
An omnichannel conversational AI for a direct-to-consumer hair-oil brand—built to answer with brand and customer context, connect to the ERP and service providers, and take approved actions through its tools.
RAGAGENTIC WORKFLOWSOMNICHANNELERP INTEGRATION

01 / THE CUSTOMER PROBLEMHaircare discovery and order support share one conversation—but not one source of truth.
Before purchase, shoppers need help navigating product fit, ingredients, routine, and usage. After purchase, the questions shift to an individual order or customer request. Both can arrive through different channels, but the information behind them is spread across approved brand material, customer records, service providers, and the ERP.
A FAQ bot leaves the operational question unanswered. A model connected directly to every record and action creates a different risk: it can retrieve too much, confuse old product content with live order state, or attempt an operation outside the request. The system had to identify the task first, fetch only the relevant context, and keep answers distinct from actions.
THE ENGINEERING REQUIREMENTGive customers a continuous conversational experience while keeping product guidance grounded, customer data scoped, and transactional changes under deterministic system control.
02 / SYSTEM DESIGNA layered request path—not a single prompt with access to everything.
A / SOURCE PIPELINEPrepare the brand’s knowledge for retrieval
Product details, ingredient lists, usage guidance, and support policies need to be normalized into retrievable records with product and source metadata. Version and freshness matter: a discontinued item or revised instruction must not remain indistinguishable from current guidance.
B / INTENT ROUTINGIdentify what the customer is trying to do
Separate product discovery and usage questions from customer-specific service requests. This determines whether the next step is a knowledge answer, a clarifying question, a live system lookup, or an approved tool action.
C / GROUNDED RETRIEVALRetrieve a narrow, relevant context
Search the appropriate product or support material using the intent and current conversation. Use source metadata and relevance thresholds; when reliable support is missing or sources conflict, ask for clarification or decline to make a claim rather than fill gaps with model memory.
D / CUSTOMER CONTEXTKeep private records out of broad retrieval
Customer-specific context comes from connected systems, not from a shared product-knowledge index. Resolve identity and authorize access outside the language model, then retrieve only the fields needed for that request.
E / PROVIDERS + ERPMake system state authoritative
Provider and ERP integrations normalize different response formats and authentication boundaries. Current order or account state is read from the system that owns it; retrieved documents do not override transactional records.
F / TOOL ORCHESTRATIONConstrain each action to an explicit contract
Expose only named operations with typed inputs and bounded outputs. Validate arguments and business preconditions in application logic, then use the confirmed provider response—not the model’s intention—to describe whether the action succeeded.
03 / FAILURE MODES TO DESIGN AROUNDEvery boundary creates a failure mode the customer can feel.
01Stale or contradictory product guidance
Product instructions, ingredients, availability, and service policies can change at different rates. Versioned sources and refresh checks prevent the assistant from treating a superseded answer as current; operational facts are queried live.
02High-volume customer data and cross-customer leakage
Large histories add noise and inference cost, while a missing identity boundary can expose one shopper’s details to another. The safe path resolves the customer first, enforces authorization in the service layer, and injects only task-relevant fields into the model context.
03Prompt injection in messages or retrieved content
A customer message or ingested document can contain instructions aimed at overriding the assistant. Treat user and retrieved text as untrusted data, keep policy instructions separate, and never let retrieved content grant new access or tools.
04Provider timeout, duplicate action, or partial completion
Retries can accidentally repeat a side effect; a timeout can occur after a provider has already processed a request. Bound retries, use idempotency for repeatable writes where supported, record correlation IDs, and verify final state before reporting success.
05Beauty advice crossing into medical claims
Ingredient and routine guidance must stay within substantiated brand material. The assistant should not diagnose scalp conditions, guarantee hair-growth outcomes, or invent contraindications; unsupported health-related requests need a safe, non-diagnostic response and an appropriate support path.
04 / GUARDRAILS AROUND CUSTOMER DATA + ACTIONSThe model can propose a next step. The application decides what is permitted.
DATA BOUNDARYIdentity verification and authorization happen in the service layer. Scope customer and order lookups to the authenticated customer; do not let the model select arbitrary customer records or expand its own permissions.
ACTION BOUNDARYUse an allow-list of task-specific tools, strict input schemas, and server-side business-rule checks. Require customer confirmation for consequential or irreversible actions; never treat natural-language intent as authorization by itself.
ANSWER BOUNDARYGround product claims in approved, current source material. Set a minimum evidence threshold, retain source provenance for review, and ask, abstain, or route to the support process when evidence is missing or conflicting.
OUTPUT BOUNDARYValidate model output before rendering it or passing fields to a provider. Keep secrets out of prompts and logs, redact unnecessary personal data, and retain an auditable record of the tool request, authorization decision, provider result, and response status.
FAILURE BOUNDARYApply timeouts, bounded retries, rate limits, and provider-specific failure handling. If the system cannot verify a result, say the action could not be confirmed; do not present a guessed or partially completed transaction as successful.
EVALUATION BOUNDARYTest the full conversation and tool path—not only answer fluency—including prompt injection, wrong-customer access, unsupported product claims, stale records, malformed arguments, duplicate calls, and provider outages.
Treat retrieved content as evidence, customer identity as an authorization boundary, and every tool call as a controlled transaction—not as a privilege granted to the model.
05 / PERFORMANCE + COST CONTROLSpend reasoning and context only where they improve the outcome.
Large prompts are not a substitute for relevant context. Keep customer history out of the default request; retrieve product records by intent; pass a compact, structured tool result back to the conversation. Stable, public product content can use a cache with a refresh policy, while personal or transactional responses must not be reused across customers.
Route simple, well-defined intents through a lighter path and reserve deeper reasoning for ambiguous or multi-step requests. Keep deterministic lookups and business rules outside the model. This reduces unnecessary input tokens and avoids paying for complex generation when a direct retrieval or provider call is enough.
Track p95 response latency, input/output tokens per resolved conversation, retrieval relevance, grounded-answer rate, tool success and failure, and cost per completed task. Optimize the inference layer against these together: lower token cost is not a win if it increases wrong answers, failed actions, or support rework.
06 / WHAT THE SYSTEM ENABLESA conversational layer that can answer with context and move work forward.
Consistent channel experienceMultiple customer-facing providers connect to a common conversation and orchestration layer.
Product answers with provenanceRAG grounds product and usage guidance in the brand’s knowledge rather than generic model memory.
Customer-specific service pathsERP and provider integrations supply live business context and expose approved actions to the assistant.
Operational controlData access, action permissions, failure behavior, and evaluation can be handled as explicit system boundaries.
The architecture moves beyond an information-only bot: it connects customer intent to current business state and controlled operations, while the ERP and integrated providers remain authoritative. The brand gets a path from discovery and support questions through to an action in the systems running its business.