MediMate: An Agent-Based AI Framework for Healthcare E-Commerce with Multi-Agent Retrieval-Augmented Generation and Technical Validation

1.1 Problem statement

Healthcare product markets are known to have common characteristics of information diffusion issues. Product information is broken down and scattered across vendor-specific pages; Price structures are heterogeneously represented; Specifications are non-standardized for products. Healthcare professionals and consumers face tangible frictions while trying to:

• Retrieve verified product information (ingredients, certifications, usage instructions).
• Compare products across multiple vendors with consistent attributes.
• Execute authenticated transactions with established providers.
• Access comprehensive data within acceptable response time windows.

These functionalities are not combined into one platform that exists at scale, particularly for healthcare; this is fundamentally different from general e-commerce.

1.2 Technical approach

We implement MediMate as a multi-agent system rather than a monolithic conversational AI. This architectural choice-decisively different from the single-large language model (LLM) approaches-emerges from the observed gaps in performance during initial prototyping. The system includes:

1. Validator Agent: Query sanitization, security screening, language detection.
2. Router Agent: Intent classification via hybrid keyword + rule-based methods.
3. General Information Agent: RAG-powered product detail retrieval.
4. Comparison Agent: Multi-product extraction and comparative synthesis.
5. Order Agent: Transaction processing with authentication/authorization
6. Summarization Agent: Long-form document distillation.

Each agent operates independently on its target task, reducing individual computational load while improving per-task accuracy. Integration uses FastAPI for request handling, ChromaDB for vector storage, and llama-3.3-70b-versatile (via Groq infrastructure) for generation tasks.

1.3 Contributions

This study proposes three innovations:

1. Multi-agent architecture surpasses monolithic systems on a variety of task groups by 24 percentage points in our healthcare product domain. This gap appears structural rather than training-related, pointing towards basic architectural benefits for heterogeneous query processing.
2. Hence, simple RAG suffices for the product-domain queries without Advanced RAG complexity. Healthcare Product queries usually look for single-hop and fact-based attributes such as price, certification, and ingredients. Reasoning across complex knowledge graphs: Simple RAG achieves an accuracy of 92% while maintaining 425 ms latency; At the margin, minor gains for Advanced RAG are not worth the latency penalty.
3. Empirical cost-benefit analysis validates model size selection despite per-token economics. The 70B model appears more expensive per token ($\$$0.59/1M) than 8B ($\$$0.02/1M), but total cost-per-interaction ($\$$0.018 vs. $\$$0.011) favors the larger model when latency-driven retry penalties are included. Organizations operating at scale (> 10K queries/day) observe 8-12% net cost reductions.

3.1 System architecture

MediMate implements a pipeline architecture as shown in Figure 1.

Figure 1. Architecture of agent-based query processing

User Query is directed to the Validator Agent which checks the syntax, security, language after that it is given to a Router Agent where it undergoes an intent classification after which it is handled by Task-Specific Agent (general info, comparison, order, summarization) then to Response Validation and finally to the Formatted Response.

Each component is described below with algorithmic precision.

3.2 Query validator agent

Input: User query string

Output: (valid: bool, error_message: str)

Algorithm:

1. Length check: 5 < len(query) < 2000 characters

• Rationale: <5 chars are noise (single words, emoji); >2000 indicate prompt injection attempts or malformed documents

• Observed filtering: 12 malicious inputs during 2-week evaluation

2. Security pattern matching: Check for SQL injection signatures, code execution patterns is specified in Table 2.

• Patterns: ' OR '1'='1, <script>, exec(), import os

• Observed filtering: 47 queries blocked during testing

• Approach: Not a complete WAF, but catches obvious attacks without false positives

3. Language detection: Identify query language, accept English/Hindi/Spanish with future expansion

• Implementation: langdetect library with confidence threshold 0.95

• Non-English queries logged but not rejected; provide valuable expansion data

Invalid query response:

Rather than silently dropping invalid queries, system triggers clarification prompt: "I didn't quite understand. Could you rephrase your question?"

Table 2. Pattern Recognition with keywords

3.3 Router agent: Intent classification

Input: Validated query (string)

Output: Intent class ∈ {GENERAL_INFO, COMPARISON, RECOMMENDATION, SUMMARIZATION, ORDER, UNKNOWN}

Classification method: Hybrid keyword + rule-based (no trained ML model)

Intent patterns:

Fallback solution: If no pattern has been matched with confidence ≥ 0.80, mark it as UNKNOWN and request that the user provide further explanation.

Reasons for a rule-based approach:

• Fast (no model inference required)
• Interpretable (rules are auditable)
• Low false positive rate in practice
• Degrades gracefully (defaults to clarification)

3.4 General information agent: RAG pipeline

Knowledge base schema (ChromaDB):

json

{

  "product_id": "MED_001",

  "name": "Product Name",

  "brand": "Brand",

  "category": "Supplements",

  "price": 249.99,

  "currency": "INR",

  "description": "Detailed description...",

  "ingredients": ["Ingredient1", "Ingredient2"],

  "certifications": ["ISO 9001", "FDA Approval"],

  "manufacturer": "Manufacturer",

  "usage_instructions": "...",

  "side_effects": "...",

  "storage_conditions": "...",

  "source_url": "authorized_provider.com"

}

RAG pipeline (Simple RAG):

Embedding: Query converted to embedding via Sentence-Transformers (all-MiniLM-L6-v2, 384-dim)

Retrieval: Cosine similarity search in ChromaDB; retrieve top-5 documents

Filtering: Apply similarity threshold ≥0.65

Rationale: 0.75+ threshold missed relevant products due to embedding variance; 0.55 introduced noise; 0.65 optimized precision-recall for 2-week evaluation dataset

Augmentation: Concatenate full text of top-5 documents into LLM prompt

Generation: LLM generates response grounded in retrieved documents, instructed to not extrapolate

Validation: Check that cited product attributes appear in retrieved documents; spot-check 47 responses manually for hallucinations (observed 0)

Similarity metric: "sim"(q,d)=(q⋅d)/(∣∣q∣∣×∣∣d∣∣)

3.5 Comparison agent

Input: Query specifying 2+ products to compare

Output: Comparison matrix + narrative summary

Algorithm:

Entity extraction: Named entity recognition to identify product names/variants

Feature selection: Determine comparison dimensions (price, brand, certifications, key ingredients)

Data extraction per product:

Query ChromaDB for curated data

Web scraping authorized domains (whitelist: 1mg.com, amazon.in, flipkart.com, netmeds.com, pharmeasy.in)

Extract structured data (JSON-LD preferred, CSS selectors fallback)

Validate stock status

Data cleaning:

Remove non-product text

Normalize prices to common currency (INR)

Validate health-related keywords for accuracy

Matrix construction: Create comparison table

Narrative synthesis: LLM generates prose summary with confidence notes for web-scraped vs. curated data

Disclaimer: "This comparison is for informational purposes; consult a healthcare provider for medical advice."

3.6 Order agent: Authentication and authorization

Security workflow:

  User submits order (product_id, quantity, delivery_address)

Authenticate: Verify JWT session token, check user role ∈ {PATIENT, HEALTHCARE_PROFESSIONAL, ADMIN}

Authorize: Check if user/provider can transact with specified product

PATIENT: Can order from all AUTHORIZED_PROVIDERS

HEALTHCARE_PROFESSIONAL: Can order from MEDICAL_SUPPLIERS subset only

Provider validation: Query authorized_providers table for active, verified providers

Order creation: Insert order record in MongoDB

Confirmation email: Send to registered email address

Fallback: If not authorized, return list of available authorized providers

Authorization table schema:

text

authorized_providers:

- provider_id (PK)

- provider_name

- api_endpoint

- verification_status (PENDING/VERIFIED/REVOKED)

- last_verification_date

- supported_product_categories

3.7 Summarization agent

Input: Long-form text or retrieved documents

Output: Concise summary (bullet points, paragraph, or comparison format)

Algorithm:

Scope identification: Extract key terms (brand, product type, certifications), identify critical details

Extractive summarization: TF-IDF scoring to identify top sentences (select 30-40% of original length)

Abstractive summarization: LLM rewrites into concise form

Target length: 50-100 words (bullets), 100-200 words

Format options:

Bullet points: 5-7 key facts

Paragraph: Continuous narrative

Comparison: Side-by-side key differences

Readability check: Flesch-Kincaid scoring; target 8-10 grade level.

3.8 Infrastructure and model specifications

LLM: groq/llama-3.3-70b-versatile via Groq Cloud API

Backend: FastAPI 0.104, Python 3.9

Vector database: ChromaDB 0.4.3

Embeddings: Sentence-Transformers (all-MiniLM-L6-v2, 384-dim)

Authentication: JWT tokens

Transaction storage: MongoDB

Hardware (development): Intel i7 (8 cores, 16GB RAM), NVIDIA RTX 3050 (8GB VRAM) for local embeddings.

5.1 Multi-agent architecture findings

The difference of 24 percent in accuracy for multi-agent systems relative to the monolithic method seems to be quite robust. The margin of improvement also does not reduce when more data is used for training, which can potentially point to reasons related to structure rather than training data itself. Specialization allows for optimization of each of the agents independently for the task for which it specializes.

The router agent's 92% classification accuracy matters disproportionately. Misclassification cascades: an order request misclassified as general information triggers RAG retrieval rather than transaction processing. The ablation study shows this single component contributes 24 points of system accuracy.

5.2 Simple vs. advanced Retrieval-Augmented Generation

Our finding that Simple RAG achieves sufficient accuracy (92%) for product domains without Advanced RAG complexity contradicts some recent literature emphasizing sophisticated RAG variants. However, the distinction likely reflects problem-domain characteristics:

• Advanced RAG benefits: Complex reasoning, multi-hop inference, structured knowledge graphs.
• Simple RAG sufficient for: Factual attributes, structured product data, deterministic lookups.

MediMate operates in the latter domain. Healthcare product queries don't typically require "What ingredients interact with condition X?" (multi-hop). They ask "What's in it?".

In other words, latency penalties from Advanced RAG are greater than accuracy gains from simple RAG: 2-3x vs. 1-2 points, accordingly. That makes simple RAG economically superior.

5.3 Cost-benefit dynamics

The economic justification for the 70B model has to be based on latency penalties. Organizations operating at <1K queries/day might find 8B or local 7B cost-effective. For enterprise scale (>10K queries/day), the 70B model's faster.

Inference prevents retry cascades that make small per-token cost differences compound. This analysis underlines the relevance of total cost-of-operation metrics beyond simple per-token pricing.

5.4 Scaling limitations

ChromaDB’s vector search functionality becomes a bottleneck when 10+ users are concurrent. This is understood to be a result of using a single instance. This should be improved by using distributed infrastructure for vector searches (e.g., Pinecone or Weaviate), which is to be addressed in our roadmap.

The system architecture (FastAPI + stateless agents) is horizontally scaled, but the bottleneck is particularly in vector retrieval and not in routing requests.

5.5 Limitations and threats to validity

Data Scope: Applies to a data set of over 100 products in the supplements, OTC, or medical device space, but does not apply or generalize to prescription drugs or clinical decision support systems. Our assessment is confined to e-commerce.

Evaluation time: 50 users for a 2-week trial is good initial proof, but not indicative of behavior patterns or seasonal changes on a large scale.

Web scraping dependencies: The Comparison agent uses trusted domains; if web scraping involves a change to their HTML layout, their CSS may become fragile. This was noted to be a vulnerable point.

Hallucination assessment: Manual checking of 47 responses is a small sample size, and a bigger random sample would have been useful in assessing claims of hallucinations.