Multi-Brand Conversational Commerce
1 · Recipe Purpose
Goal | Outcome |
---|---|
Portfolio-level discovery | One shopping assistant can surface SKUs from all your house-of-brands in a single conversation. |
Cross-sell & upsell | Context-aware recommendations that bridge brand silos. |
Agent readiness (MCP Server) | Brand catalogs appear in ChatGPT, Perplexity, Gemini via standardized capability APIs. |
Shared architecture | Abstract disparate e-commerce platforms behind a unified orchestration layer—future back-end swaps require zero front-end change. |
Success criteria
/crossBrandDiscovery
returns SKUs from both brands- POC live in ≤ 8 weeks for two reference brands.
- Register MCP Server with the MCP Registry
2 · Architecture at a Glance
Here is the flow diagram for the extended use case of completing transactions through the Conversational Interface:
3 · System Inventory
Component | Role in Discovery | Role in Checkout | Notes / Key Responsibilities |
---|---|---|---|
Chat UI + MCP Client | Sends natural-language query to LLM; invokes /crossBrandDiscovery on MCP. | Sends “Checkout my cart” intent; invokes /checkout on MCP. | Adds account context & auth headers; handles retries and error states. |
LLM | Detects crossBrandDiscovery intent, formulates function call; returns conversational summary of SKU list. | Detects checkout intent; turns order confirmation payload into natural-language reply. | Stateless regarding enterprise data; never hits raw back-ends. |
MCP Server | Gateway for /crossBrandDiscovery and other tools to complete discovery and transactions through the conversational interface; enforces auth, rate-limits, audit. | Gateway for /checkout ; same controls. | Central capability registry; emits trace-IDs. |
Orchestration Layer | Flow: discovery.crossBrand — fan-out hybrid search to two catalog indexes, merge, rank. | Flow: checkout — price, stock reserve, tax, credit check, payment auth, order commit. | No/low-code; central place for rules, mapping, conditional logic. |
Catalog A Search Index | Hybrid keyword + vector search; returns SKUs for Brand A. | Not used. | Nightly/full feed + webhook delta updates. |
Catalog B Search Index | Same as above for Brand B. | Not used. | Same freshness strategy. |
Pricing Service | Adds contract/volume price during enrichment (optional). | Calculates final line prices and order total. | Must support bulk pricing for performance. |
Availability Service | Supplies real-time stock for discovery enrichment (optional). | Reserves stock and validates availability before order commit. | Returns buckets per SKU × location. |
Tax Service | Not called. | Computes jurisdictional tax and duties for cart. | Accepts destination, product class, exemptions. |
Payment Service | Not called. | Authorises or captures payment (card / ACH / terms). | PCI-scoped; returns auth token or decline. |
ERP / OMS | Not called. | Checks credit limit; creates authoritative order record; returns order ID + ETA. | Single source of truth for orders and credit status. |
Operational Data Repository (ODR) | Hosts search indexes and cached SKU/price snapshots to hit discovery SLA. | Optional cache for price & stock to reduce latency in peak periods. | Can store popular query embeddings or pre-priced carts. |
Catalog Data Feeds | Nightly batch & webhook delta to keep indexes fresh. | Same feeds supply up-to-date product data for pricing/stock. | Managed by platform teams; monitored via change-event logs. |
4 · Orchestration Flows
Here is the sequence diagram for the multi-brand discovery flow:
Here is a sample sequence flow for extending this use case to complete transactions through the conversational interface:
Additional Notes
- The Search Index for Catalog A and B can be any search platform that offers lexical and semantic search. This means that Conscia's Orchestration Layer can sit on top of existing search platforms such as Algolia, Constructor, Bloomreach, etc.
- This sequence flow can easily be extended to included use cases such as cross-sells & recommendations, inventory-aware search, etc.
5 · Implementation
Phase | Step | Description | Owners / Tools |
---|---|---|---|
0. Kick-Off & Design | 0.1 | Define search contract – JSON schema for request (accountId , query , locale , k ) and response (array of sku , brand , title , price , vectorScore , keywordScore ). | Solution Architect + Backend Lead |
0.2 | Decide ranking formula – e.g., 0.7 × semanticScore + 0.3 × keywordScore , tie-breaker on price ascending. | Search Relevance SME | |
1. Data Preparation | 1.1 | Extract catalogs: full product feed (ID, title, bullets, price) from Platform A & B. | Platform Teams |
1.2 | Generate embeddings for title + description with same model (e.g., OpenAI text-embedding-3-small ). | Data Engineering | |
1.3 | Load Search Indexes: • IDX_A = Algolia, OpenSearch, Vespa, or Pinecone hybrid mode• IDX_B same stack, separate namespace. | Search Ops | |
1.4 | Set delta feeds – webhook on product publish/price change triggers re-index within ≤ 5 min SLA. | DevOps | |
2. MCP Server Changes | 2.1 | Add capability spec: /crossBrandDiscovery to the MCP OpenAPI file (method POST). | API Lead |
2.2 | Auth & rate limits – bearer token; 30 rps burst, 10 rps sustained per IP. | Security / SRE | |
3. Orchestration Layer | 3.1 | Build flow “discovery.crossBrand” 1. Accept request. 2. Fan-out hybrid search to IDX_A & IDX_B (k = ceil(n/brands) to hit desired total).3. Merge lists; compute blended relevance. 4. Trim to top n (default = 10). | Low-code flow builder (Conscia DXO) |
3.2 | Unit tests – mock indexes; assert merge order, dedupe identical SKUs across brands. | QA | |
4. Chat Tier Integration | 4.1 | Update MCP Client SDK to add crossBrandDiscovery() helper method that wraps HTTP call + auth token. | Front-end Dev |
4.2 | LLM tool definition – add JSON schema in system prompt so LLM can call the new capability. | Prompt Engineer | |
4.3 | Guardrail prompt – instruct LLM to limit result set to max 6 SKUs and always include brand label. | Prompt Engineer |