Industry

HydraDB for

Insurance AI

Insurance relationships span decades, but standard AI agents forget policy changes the moment a session ends. HydraDB gives your claims copilots and underwriting agents persistent, audit-grade memory across policy documents, historical claims, and customer communications. Stop building brittle custom ETL pipelines to feed vector databases, and give your agents the infrastructure to track evolving coverage, map complex fraud relationships, and retrieve deterministic decision traces required by regulators.

Start building

Book a demo

90%

Recall accuracy on LongMemEval

<200ms

Context retrieval latency

1B+

Documents ingested

40%

Reduction in repeat contacts

// The Problem //

Why insurance AI keeps failing

Most engineering teams building AI for claims and underwriting rely on standard vector databases or massive context windows. In highly regulated environments, this results in agents that hallucinate coverage dates, miss multi-level fraud signals, and generate unexplainable decisions.

Flattened policy timelines

Standard vector databases flatten time. When an agent searches for a policyholder's coverage limits, it retrieves outdated endorsements from three years ago mixed with current active policies. Without temporal awareness, the AI cannot confidently determine what was true on the date of loss.

Flattened policy timelines

Flattened policy timelines

Black-box decision traces

Regulators demand auditability for underwriting and claims decisions. Relying on an LLM to synthesize raw text chunks from a vector store creates a "black box" where the exact source and lineage of a decision are lost, failing compliance requirements.

Black-box decision traces

Fragmented claimant relationships

Fraud detection requires mapping relationships across siloed data. Because traditional RAG treats data as isolated text chunks, agents fail to connect a new claimant to a previously flagged property, missing critical second- and third-degree network connections.

Fragmented claimant relationships

Context window limits

Stuffing a 150-page commercial policy, five years of claim history, and regulatory statutes into an LLM's context window is expensive and unreliable. It rapidly hits token limits and causes "lost in the middle" behavior where critical exclusions are entirely ignored.

Context window limits

// See It In Action //

An agent that actually remembers

Once your policy and claims data is ingested and structured by HydraDB, it assembles the full historical context before your LLM responds. It pulls precisely the right policy state, entity relationships, and temporal facts without token-heavy prompt stuffing.

Live support session — HydraDB context active

Retrieval : 94ms

Did the policyholder have active flood coverage when the storm hit on May 12, and has this property been flagged for suspicious claims before?

Claims adjuster

Insurance claim review

Date of loss: May 12

HydraDB recalled:

Fact: Flood endorsement added to Policy #8821 on April 15

Temporal State: Active coverage confirmed for May 12 (Policy effective: Jan 1 - Dec 31)

Relationship: Property (123 Oak St) → Previously flagged for → Water damage claim (Claim #449, 2021)

Document: Guidewire claim record updated May 14 (Status: Pending Review)

Yes, the policyholder had active flood coverage on May 12. The flood endorsement was added on April 15, within the policy's effective period (Jan 1 - Dec 31). However, the property at 123 Oak St was previously flagged for a water damage claim in 2021 (Claim #449). The Guidewire record shows status 'Pending Review' as of May 14. I have attached the lineage for this decision. Recommend proceeding with manual underwriter review.

// How Hydra Helps //

Context Infrastructure for Insurance AI

HydraDB replaces fragmented vector search and custom memory logic with a single graph-native context layer designed for the strict requirements of insurtech engineering teams building claims agents and underwriting copilots.

Persistent memory

HydraDB stores the full lifecycle of a policyholder as structured memory. Every claim document, customer email, and policy endorsement you ingest is processed and indexed, giving your AI continuous, cross-session memory of the customer's history.

Persistent memory

Persistent memory

Relationship-aware retrieval

HydraDB models complex insurance entities natively through its context graph. It can link a new claim record to an older suspicious address, connecting people, properties, vehicles, and historical decisions into a single retrievable graph for deep case analysis.

Relationship-aware retrieval

Temporal context

HydraDB tracks how customer requirements and coverage limits evolve over time. Knowledge is stored as a Git-style versioned graph. Your agent can query what coverage was active on the exact date of loss versus what is active today, tracking state changes with 90.97% temporal reasoning accuracy.

Temporal context

Connector-native ingestion

HydraDB ingests structured records from core insurance systems. Map your extracted data from Guidewire, Duck Creek, Salesforce Financial Services Cloud, SharePoint, and Amazon S3 into HydraDB's format, and the system resolves entities, links related records, and extracts critical facts at ingestion time.

Connector-native ingestion

// Get Started //

Three steps to production-ready memory

HydraDB works with any LLM or AI framework. Replace custom ETL pipelines and prompt stuffing with precise, structured context retrieval by mapping records from your core systems into HydraDB.

Connect your Guidewire and S3 sources

Use your core system APIs or scheduled batch exports to retrieve the policy documents, claim records, and customer communications you want HydraDB to remember.

import os
from hydra_db import HydraDB

client = HydraDB(token=os.environ.get("HYDRA_KEY"))

# Retrieve a claim record and a policy document using
# your existing system APIs or S3 buckets
claim_record = guidewire_client.get_claim(claim_id="CLM-449")
policy_doc = s3_client.get_object(bucket="policies", key="POL-8821.pdf")

import os
from hydra_db import HydraDB

client = HydraDB(token=os.environ.get("HYDRA_KEY"))

# Retrieve a claim record and a policy document using
# your existing system APIs or S3 buckets
claim_record = guidewire_client.get_claim(claim_id="CLM-449")
policy_doc = s3_client.get_object(bucket="policies", key="POL-8821.pdf")

import os
from hydra_db import HydraDB

client = HydraDB(token=os.environ.get("HYDRA_KEY"))

# Retrieve a claim record and a policy document using
# your existing system APIs or S3 buckets
claim_record = guidewire_client.get_claim(claim_id="CLM-449")
policy_doc = s3_client.get_object(bucket="policies", key="POL-8821.pdf")

Connect your Guidewire and S3 sources

Use your core system APIs or scheduled batch exports to retrieve the policy documents, claim records, and customer communications you want HydraDB to remember.

import os
from hydra_db import HydraDB

client = HydraDB(token=os.environ.get("HYDRA_KEY"))

# Retrieve a claim record and a policy document using
# your existing system APIs or S3 buckets
claim_record = guidewire_client.get_claim(claim_id="CLM-449")
policy_doc = s3_client.get_object(bucket="policies", key="POL-8821.pdf")

Connect your Guidewire and S3 sources

Use your core system APIs or scheduled batch exports to retrieve the policy documents, claim records, and customer communications you want HydraDB to remember.

import os
from hydra_db import HydraDB

client = HydraDB(token=os.environ.get("HYDRA_KEY"))

# Retrieve a claim record and a policy document using
# your existing system APIs or S3 buckets
claim_record = guidewire_client.get_claim(claim_id="CLM-449")
policy_doc = s3_client.get_object(bucket="policies", key="POL-8821.pdf")

Ingest and structure policy context

Structure each record using HydraDB's typed fields so the platform can resolve entities, map relationships, and apply temporal boundaries at ingestion time.

import json

# Ingest the claim record and policy data. HydraDB resolves
# entities (like the property address) and links them at indexing time
client.context.ingest(
    type="knowledge",
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    app_knowledge=json.dumps([
        {
            "id": "claim_449",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Water Damage Claim - 123 Oak St",
            "type": "guidewire",
            "content": {"text": f"Status: {claim_record.status}, Notes: {claim_record.notes}"},
            "metadata": {"propertyAddress": "123 Oak St", "flagged": True}
        },
        {
            "id": "policy_8821_endorsement",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Flood Endorsement",
            "type": "policy_document",
            "content": {"text": "Flood coverage added. Limit: $150,000."},
            "metadata": {"effectiveDate": "2023-04-15", "expirationDate": "2023-12-31"}
        }
    ])
)

import json

# Ingest the claim record and policy data. HydraDB resolves
# entities (like the property address) and links them at indexing time
client.context.ingest(
    type="knowledge",
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    app_knowledge=json.dumps([
        {
            "id": "claim_449",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Water Damage Claim - 123 Oak St",
            "type": "guidewire",
            "content": {"text": f"Status: {claim_record.status}, Notes: {claim_record.notes}"},
            "metadata": {"propertyAddress": "123 Oak St", "flagged": True}
        },
        {
            "id": "policy_8821_endorsement",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Flood Endorsement",
            "type": "policy_document",
            "content": {"text": "Flood coverage added. Limit: $150,000."},
            "metadata": {"effectiveDate": "2023-04-15", "expirationDate": "2023-12-31"}
        }
    ])
)

import json

# Ingest the claim record and policy data. HydraDB resolves
# entities (like the property address) and links them at indexing time
client.context.ingest(
    type="knowledge",
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    app_knowledge=json.dumps([
        {
            "id": "claim_449",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Water Damage Claim - 123 Oak St",
            "type": "guidewire",
            "content": {"text": f"Status: {claim_record.status}, Notes: {claim_record.notes}"},
            "metadata": {"propertyAddress": "123 Oak St", "flagged": True}
        },
        {
            "id": "policy_8821_endorsement",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Flood Endorsement",
            "type": "policy_document",
            "content": {"text": "Flood coverage added. Limit: $150,000."},
            "metadata": {"effectiveDate": "2023-04-15", "expirationDate": "2023-12-31"}
        }
    ])
)

Ingest and structure policy context

Structure each record using HydraDB's typed fields so the platform can resolve entities, map relationships, and apply temporal boundaries at ingestion time.

import json

# Ingest the claim record and policy data. HydraDB resolves
# entities (like the property address) and links them at indexing time
client.context.ingest(
    type="knowledge",
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    app_knowledge=json.dumps([
        {
            "id": "claim_449",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Water Damage Claim - 123 Oak St",
            "type": "guidewire",
            "content": {"text": f"Status: {claim_record.status}, Notes: {claim_record.notes}"},
            "metadata": {"propertyAddress": "123 Oak St", "flagged": True}
        },
        {
            "id": "policy_8821_endorsement",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Flood Endorsement",
            "type": "policy_document",
            "content": {"text": "Flood coverage added. Limit: $150,000."},
            "metadata": {"effectiveDate": "2023-04-15", "expirationDate": "2023-12-31"}
        }
    ])
)

Ingest and structure policy context

Structure each record using HydraDB's typed fields so the platform can resolve entities, map relationships, and apply temporal boundaries at ingestion time.

import json

# Ingest the claim record and policy data. HydraDB resolves
# entities (like the property address) and links them at indexing time
client.context.ingest(
    type="knowledge",
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    app_knowledge=json.dumps([
        {
            "id": "claim_449",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Water Damage Claim - 123 Oak St",
            "type": "guidewire",
            "content": {"text": f"Status: {claim_record.status}, Notes: {claim_record.notes}"},
            "metadata": {"propertyAddress": "123 Oak St", "flagged": True}
        },
        {
            "id": "policy_8821_endorsement",
            "tenant_id": "national_ins",
            "sub_tenant_id": "acct_smith_j",
            "title": "Flood Endorsement",
            "type": "policy_document",
            "content": {"text": "Flood coverage added. Limit: $150,000."},
            "metadata": {"effectiveDate": "2023-04-15", "expirationDate": "2023-12-31"}
        }
    ])
)

Retrieve full context at inference time

Before your agent answers a claims query or makes an underwriting recommendation, query HydraDB for precise, time-aware history and entity relationships.

# Retrieve structured policy history and fraud signals before LLM generation
result = client.query(
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    query="Was flood coverage active on May 12, and are there prior claims for this property?",
    type="knowledge",
    mode="thinking",
    query_apps=True
)

# Pass the exact, auditable context to your LLM
response = llm.chat(
    system=build_compliance_prompt(result.data),
    user="Draft an initial review summary for the adjuster."
)

# Retrieve structured policy history and fraud signals before LLM generation
result = client.query(
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    query="Was flood coverage active on May 12, and are there prior claims for this property?",
    type="knowledge",
    mode="thinking",
    query_apps=True
)

# Pass the exact, auditable context to your LLM
response = llm.chat(
    system=build_compliance_prompt(result.data),
    user="Draft an initial review summary for the adjuster."
)

# Retrieve structured policy history and fraud signals before LLM generation
result = client.query(
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    query="Was flood coverage active on May 12, and are there prior claims for this property?",
    type="knowledge",
    mode="thinking",
    query_apps=True
)

# Pass the exact, auditable context to your LLM
response = llm.chat(
    system=build_compliance_prompt(result.data),
    user="Draft an initial review summary for the adjuster."
)

Retrieve full context at inference time

Before your agent answers a claims query or makes an underwriting recommendation, query HydraDB for precise, time-aware history and entity relationships.

# Retrieve structured policy history and fraud signals before LLM generation
result = client.query(
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    query="Was flood coverage active on May 12, and are there prior claims for this property?",
    type="knowledge",
    mode="thinking",
    query_apps=True
)

# Pass the exact, auditable context to your LLM
response = llm.chat(
    system=build_compliance_prompt(result.data),
    user="Draft an initial review summary for the adjuster."
)

Retrieve full context at inference time

Before your agent answers a claims query or makes an underwriting recommendation, query HydraDB for precise, time-aware history and entity relationships.

# Retrieve structured policy history and fraud signals before LLM generation
result = client.query(
    tenant_id="national_ins",
    sub_tenant_id="acct_smith_j",
    query="Was flood coverage active on May 12, and are there prior claims for this property?",
    type="knowledge",
    mode="thinking",
    query_apps=True
)

# Pass the exact, auditable context to your LLM
response = llm.chat(
    system=build_compliance_prompt(result.data),
    user="Draft an initial review summary for the adjuster."
)

// Why HydraDB //

HydraDB vs. Standard Vector Search for Insurance

HydraDB replaces fragmented vector search and custom memory logic with a single graph-native context layer designed for insurance AI workflows.

Features

HydraDB

Standard Vector Search

Cross-session memory

Stores persistent policyholder history across multi-year lifecycles

Treats every query as an isolated lookup with no historical continuity

Relationship-aware retrieval

Connects claimants, properties, and past cases in a traversable graph

Retrieves isolated text chunks based purely on semantic similarity

Temporal context

Tracks evolving coverage limits and policy dates via a versioned graph

Flattens time, often surfacing outdated exclusions as current truth

Auditability & Lineage

Provides deterministic decision traces linking AI outputs to specific facts

Black-box retrieval makes it difficult to prove why a chunk was selected

Integration method

Structured records mapped to a typed format from core systems

Requires custom chunking, ETL pipelines, and manual entity resolution

Best fit

Claims agents, underwriting copilots, and compliance workflows

Semantic search over static employee handbooks and generic FAQs

Features

Cross-session memory

Relationship-aware retrieval

Temporal context

Auditability & Lineage

Integration method

Best fit

HydraDB

Stores persistent policyholder history across multi-year lifecycles

Connects claimants, properties, and past cases in a traversable graph

Tracks evolving coverage limits and policy dates via a versioned graph

Provides deterministic decision traces linking AI outputs to specific facts

Structured records mapped to a typed format from core systems

Claims agents, underwriting copilots, and compliance workflows

Standard Vector Search

Treats every query as an isolated lookup with no historical continuity

Retrieves isolated text chunks based purely on semantic similarity

Flattens time, often surfacing outdated exclusions as current truth

Black-box retrieval makes it difficult to prove why a chunk was selected

Requires custom chunking, ETL pipelines, and manual entity resolution

Semantic search over static employee handbooks and generic FAQs

// What Teams Are Saying //

Trusted by teams building insurance AI

We needed to audit our AI systems for regulatory compliance. Standard vector search couldn't give us the lineage we needed. HydraDB's graph-native memory allows us to rapidly capture time-aware history and generate ad-hoc compliance reporting, proving exactly which policy clause drove the agent's output.

Sarah Jenkins

Head of AI Engineering, Enterprise Insurtech

Our claims agents were hallucinating because they couldn't distinguish between a policyholder's old address and their new one. HydraDB fixed the 'destructive update problem' for us overnight. It tracks the evolving state of a customer perfectly.