Transforming Insurance Agent Support with RAG-Powered Chat Assistant

insurancedekho · Insurance · 2024 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Insurance agent support

InsuranceDekho needed agents to answer customer policy questions quickly without waiting on subject matter experts, across many insurers and health plans.

Constraints:

• The platform worked with over 150,000 agents and 49 insurance companies.
• Agents could not memorize 125+ health plans from 21 insurers.
• SMEs could only handle one call at a time.
• Response delays could cause customers to abandon purchase flows.
• Insurance data required secure, private model access.

Architecture

InsuranceDekho built a RAG chat assistant on Amazon Bedrock using Claude Haiku, OpenSearch vector storage, a third-party embedding model, Redis semantic caching, and AWS PrivateLink. The workflow ingests policy documents into embeddings, checks cache for repeated queries, classifies intent, retrieves relevant policy context, and generates answers for advisors.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  advisor_chatbot["Advisor chatbot"] --> redis_semantic_cache["Redis semantic cache"]
  advisor_chatbot --> claude_haiku_intent_classifier["Claude Haiku intent classifier"]
  policy_document_ingestion["Policy document ingestion"] --> third_party_embedding_model["Third-party embedding model"]
  third_party_embedding_model --> opensearch_vector_database["OpenSearch vector database"]
  claude_haiku_intent_classifier --> rag_answer_generator["RAG answer generator"]
  opensearch_vector_database --> rag_answer_generator
  rag_answer_generator --> advisor_chatbot
  aws_privatelink["AWS PrivateLink"] --> rag_answer_generator

Components

Data flow

Policy documents are embedded and stored in OpenSearch. An advisor asks a question in the chatbot; Redis checks whether a semantically similar query was recently answered; Claude Haiku classifies intent; generic questions can be answered directly; complex questions retrieve policy context from the vector database and generate a grounded response.

Why this architecture

RAG lets agents answer policy-specific questions from current documents, while Bedrock provides managed model access, model portability, throughput options, and private connectivity.

Models used: Anthropic Claude Haiku · Claude Instant · third-party embedding model · Amazon Bedrock

Scale

• InsuranceDekho worked with over 150,000 agents and 49 insurance companies.
  “working with over 150,000 insurance agents and 49 insurance companies”summary, stated
• Agents had to cover 125+ health plans from 21 insurers.
  “Advisors couldn't be expected to memorize the details of 125+ health plans from 21 different insurers”summary, stated
• The assistant reduced response time by 80%.
  “resulting in an 80% reduction in response time”summary, stated

Alternatives considered (roads not taken)

Continue routing policy questions to SMEs

Rejected because: SMEs were a bottleneck and created customer response delays.

Use Claude Instant permanently

Rejected because: Bedrock portability let them transition to Claude Haiku without code changes.

Run every query through full RAG

Rejected because: A Redis semantic cache handles recently processed queries first.

Patterns

rag-retrieval (policy knowledge)

The assistant retrieves policy-document context from OpenSearch before generating answers.

semantic-caching (latency and cost)

Redis performs semantic lookup for recently processed queries before full RAG.

model-routing (intent handling)

Claude Haiku classifies intent and routes generic versus complex queries differently.

privacy-preserving-processing (insurance data)

PrivateLink keeps model access private rather than traversing the public internet.

Tradeoffs

Use a managed model service.

Chose Amazon Bedrock over Provisioning GPUs and ML frameworks directly.

Rationale: Managed Bedrock reduced development and deployment overhead for production LLM use.

Add semantic caching.

Chose Redis on ElastiCache over Always hitting vector search and generation.

Rationale: Repeated or similar advisor questions can be answered faster and cheaper.

Gotchas (what bit them)

Human SMEs become a support bottleneck.

Root cause: Only one call can be handled at a time and policy complexity is too broad for every agent to memorize.

Resolution: Use RAG to give advisors autonomous access to policy answers.

Model provider lock-in can slow upgrades.

Root cause: Production models change quickly and teams need portability.

Resolution: Use Bedrock's single API to transition from Claude Instant to Claude Haiku without code changes.

Evaluation

InsuranceDekho reports production business impact through response-time reduction and improved agent/customer experience.

Metrics: 150,000+ agents. · 49 insurance companies. · 125+ health plans from 21 insurers. · 80% response-time reduction.

Outcomes

• Agents could answer policy coverage, exclusion, and feature questions without SME involvement.
• Response time dropped by 80%.
• Bedrock model portability allowed transition from Claude Instant to Claude Haiku.

The platform serves over 150,000 agents across 49 insurers.