Insurance Agent

The Problem

Israelis in their 20s-40s typically hold 4-6 insurance policies: life insurance, health insurance, disability, mortgage insurance, pension, and personal accident. These policies are coordinated by different agents, sold at different times, and written in legal Hebrew that most people don’t read.

The Israeli government requires insurers to produce a “Har Bituach” (insurance mountain) — a consolidated document listing all your policies, premiums, and coverage amounts. This document exists specifically to help people understand what they have. In practice, most people receive it annually, file it somewhere, and never look at it.

The result: people pay for overlapping coverage (e.g., two disability policies with similar terms), have gaps in essential coverage (e.g., no critical illness rider), and have no idea what to do when they need to file a claim.

I built an AI agent to fix this.

The Approach

PDF Ingestion — The Har Bituach is a PDF. Hebrew PDFs are non-trivial: RTL text, complex character encoding, tables that PDF parsers frequently mangle. I used pdfplumber with custom extraction logic for Hebrew character normalization and table reconstruction. This required handling both digitally-generated PDFs (text extractable) and scanned PDFs (OCR required via pytesseract with Hebrew language model).

PII Masking — Before any text reaches an LLM, it passes through a PII masking layer. Israeli ID numbers, birth dates, addresses, and bank account numbers are detected using pattern matching and a lightweight NER model, then replaced with placeholder tokens. The LLM analyzes [ISRAELI_ID] and [NAME], not the actual values. The mapping lives only in the user’s local session. Compliance with Israeli privacy law (ILPA) is a hard requirement, not an afterthought.

Structured Policy Extraction — I define a policy schema covering: policy type, insurer, premium (monthly/annual), coverage amount, beneficiaries, and exclusions. The AI extracts each policy into this schema. Having a structured intermediate representation — not just raw text — enables deterministic overlap detection. Two policies with overlapping disability coverage are detectable via schema comparison, not LLM judgment.

Overlap and Gap Analysis — Overlap detection is rule-based: compare coverage types and amounts across policies using the extracted schema. Gap detection combines rules (does the user have disability insurance? critical illness? income protection?) with LLM analysis for context the rules miss (e.g., an exclusion in one policy creates a gap despite nominal coverage).

RAG-Powered Claims Assistant — The claims assistant grounds its responses in a vector database of Israeli insurance law, common policy terms, and claims procedure guidelines. Rather than having the LLM hallucinate claims procedures, it retrieves the relevant regulation and generates guidance grounded in that retrieved context. Standard RAG, but the retrieval corpus is domain-specific and curated.

Key Technical Decisions

FastAPI over Flask. Async-native, better type annotations via Pydantic, automatic OpenAPI docs generation. For a small team project, the auto-generated docs were immediately useful for frontend integration. FastAPI is the right default for new Python APIs.

Human-in-the-loop for MVP. The AI extracts and analyzes; a human (the user) confirms before any recommendations are acted on. I explicitly did not automate any downstream actions (canceling policies, contacting insurers). Insurance decisions are consequential. The product presents analysis and guidance — the human decides.

Separate frontend and backend. The React frontend communicates with the FastAPI backend via REST. No server-side rendering, no monolith. The separation made the frontend iterable independently and the backend independently testable. Slightly more infrastructure complexity at the cost of much cleaner development workflow.

Hebrew-first UI. Full RTL support from day one: Heebo font, dir="rtl" everywhere appropriate, PDF rendering in RTL. Adding RTL support to an LTR UI is painful. Building RTL-first from the start was the right call for the target audience.

What I Learned

Hebrew PDF parsing is a distinct engineering problem. Generic PDF parsers handle it poorly. pdfplumber handles it better, but still requires calibration for column order, table extraction, and character normalization specific to Hebrew fonts. If your product handles non-Latin documents, budget extra time for ingestion.

Schema-first extraction beats open-ended LLM analysis. The most reliable part of the system is the structured policy extraction with a defined output schema. The most variable part is open-ended LLM analysis. Whenever I could replace LLM judgment with schema comparison, I did — and accuracy improved.

Privacy architecture should determine data architecture, not the other way around. PII masking before LLM processing meant the LLM API never received raw personal data. This was a conscious design constraint from the start. If I had built the extraction first and added masking later, I would have had to rewrite significant parts of the pipeline. Treat privacy as a first-class architectural concern.