Insurance claim analysis with AI using a multi-agent architecture

Learn how to build a multi-agent AI workflow for insurance claim analysis.

Overview

Insurance claim processing is challenging. Manual reviews take a lot of time, as adjusters spend hours reviewing narratives, checking facts, looking for fraud, and estimating repair costs.

What you'll build

A multi-agent system that helps review insurance claims and improve the accuracy of fraud detection.

Key capabilities:

• Validates claim data and looks for fraud risk using AI

• Automatically estimates repair costs for valid claims

• Sends high-risk claims to fraud investigation and low-risk claims for approval

• Generates structured reports and notifies adjusters by email

Related patterns

This multi-agent fraud detection pattern can be used in different industries:

• Loan application processing: The system verifies applicant data, evaluates creditworthiness, checks for fraud, and sends the application to an underwriter.

• Healthcare claims review: The system validates medical codes, checks coverage eligibility, identifies unusual patterns, and routes the claim for approval.

• Warranty claims: The system analyzes product failures, verifies purchase legitimacy, detects abuse patterns, and either approves the claim or escalates it.

Pipeline setup

Trigger

Use a REST Trigger to receive claim data through a POST request. Keep the other settings as default.

Expected input: A claim object with information about the policyholder, the incident, the asset, the narrative, and the consent flags.

See an example payload:

{
  "claim": {
    "claim_id": "CLM-2024-12345",
    "policy_id": "POL-AUTO-98765",
    "policyholder": {
      "name": "Maria Silva",
      "customer_id": "CUST-001",
      "contact": {
        "email": "[email protected]",
        "phone": "[phone]"
      }
    },
    "incident_datetime": "2024-12-20T14:30:00Z",
    "incident_location": {
      "address": "Av. Paulista, 1000, São Paulo, SP",
      "country": "Brazil"
    },
    "incident_type": "auto",
    "narrative": "I was driving when another car ran a red light and hit my front left side...",
    "assets": [
      {
        "make": "Honda",
        "model": "Civic",
        "year": 2022
      }
    ],
    "consents": {
      "data_processing": true,
      "fraud_analytics": true
    }
  }
}

Validation

Use the Validator v2 connector to check that all required fields are present. Missing data can waste AI tokens and reduce analysis quality.

Schema design is important for production pipelines, but it’s not covered in this guide. For a deeper dive, see the Validator v2 connector documentation.

Multi-agent architecture

The integration uses three specialized agent types. One of them, the Claim Reporter, used in both paths:

• Claim Analyst: Analyzes fraud risk and identifies inconsistencies.

• Damage Analyst: Estimates repair costs for claims with low-fraud risk.

• Claim Reporter: Generates human-readable reports and adapts based on fraud path.

Why use separate agents

• Lower cost: Using the right model for each task saves 40–60% on token costs compared to using a single agent.

• Better accuracy: Specialized prompts and clear responsibilities increase precision of each step.

• Smarter routing: Claims with high fraud risk skip cost estimation and are sent directly to escalation.

Agent 1: Claim Analyst

Purpose: Evaluate fraud risk, identify inconsistencies, and recommend next steps.

Configuration:

• Model: GPT-4o (tool usage is required)

• Temperature: 1.0 (for testing purposes)

  • Higher temperature allows more nuanced reasoning during fraud assessment. This means the same input may produce slightly different fraud scores on each run. For production environments, consider lowering the temperature to 0.2 for more consistent and deterministic results.

• Max Output Tokens: 10000

• JSON Schema: See the JSON Schema for this agent below. Learn more about how to structure your output.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["fraud_assessment", "recommendation"],
  "properties": {
    "fraud_assessment": {
      "type": "object",
      "required": ["score_0_100"],
      "properties": {
        "score_0_100": { "type": "integer", "minimum": 0, "maximum": 100 },
        "signals": { "type": "array" },
        "explanation": { "type": "string" }
      }
    },
    "recommendation": {
      "type": "object",
      "required": ["action"],
      "properties": {
        "action": { "type": "string" },
        "conditions": { "type": "array" },
        "rationale": { "type": "string" }
      }
    }
  }
}

MCP Tools: Add the Tavily search tool. It can:

• Verify addresses by catching fake locations.

• Check weather consistency by verifying the narrative accuracy against actual conditions.

Without MCP configured, the agent relies on pattern analysis for fraud detection. Address and weather verification improve accuracy but are not required for the pipeline to work.

System Message:

You are an insurance claims analyst. Review the claim and produce a structured decision brief with:
- Incident summary
- Inconsistencies and missing info
- Fraud assessment with explicit signals
- Recommended action with evidence

Rules:
- Cite exact fields for all assertions
- Mark unknown data in missing_information
- Use Tavily to verify location and weather
- Follow JSON schema strictly

User Message:

CLAIM CONTEXT PACK

{{ message.claim }}

Example output:

{
  "body": {
    "fraud_assessment": {
      "score_0_100": 30,
      "signals": [
        {
          "name": "Incident Date Verification",
          "direction": "unknown",
          "weight": 0.5,
          "evidence_refs": []
        },
        {
          "name": "Weather Condition",
          "direction": "unknown",
          "weight": 0.5,
          "evidence_refs": []
        }
      ],
      "explanation": "The claim indicates...driver."
    },
    "recommendation": {
      "action": "approve_with_conditions",
      "conditions": [
        "Submit police report for verification"...
      ],
      "rationale": "Although the current evidence does not suggest fraud, the lack of detailed corroborative ...."
    }
  }
}

Routing decision

Use a Choice connector to determine the next path based on fraud risk assessment:

{
  "when": [
    {
      "target": "low-fraud",
  	 "jsonPath": $.body.fraud_assessment[?(@.score_0_100 < 40)]
    }
  ],
  "otherwise": "high-fraud"
}

Threshold logic:

• Fraud score below 40: The claim is low risk and includes damage estimation analysis.

• Fraud score 40 or higher: The claim is high risk. The damage analysis is skipped and it escalates immediately.

Low-fraud path: Complete flow

Claims with fraud scores below the threshold go through damage analysis, report generation, and adjuster notification.

1

Damage analyst agent

Purpose: Estimate repair costs by matching damaged components to a pricing database.

Configuration:

• Model: GPT-4o-mini (cost-efficient for straightforward matching)

• Temperature: 0.7

• Max Output Tokens: 1024

System Message:

Analyze repair costs. Match damaged parts identified in the claim summary to the provided price

User Message:

CLAIM CONTEXT: {{ message.body }}

AUTO PARTS REPAIR COSTS

[
  {"part": "door", "cost": 1000, "currency": "BRL"},
  {"part": "mirror", "cost": 2500, "currency": "BRL"},
  {"part": "head lights", "cost": 3000, "currency": "BRL"}
]

For simplicity, the repair cost table is embedded directly in the prompt in this example. In production scenarios, this data should come from an external source such as a database.

Example output:

{
  "body": {
    "involved_parts": [
      {
        "part_name": "door",
        "estimated_cost_to_repair": 1000
      },
      {
        "part_name": "mirror",
        "estimated_cost_to_repair": 2500
      },
      {
        "part_name": "head lights",
        "estimated_cost_to_repair": 3000
      }
    ],
    "estimated_total_cost_to_repair": 6500
  }
}

2

JSON Generator (Combine results)

Purpose: Combine claim analysis with damage analysis to create a comprehensive data package.

Configuration:

{
  "claim": {{ step.claim-analyst.body }},
  "damage": {{ message.body }}
}

Why this step?

The Claim Reporter requires both outputs:

• Fraud assessment, consistency checks, and recommendation from the Claim Analyst.

• Repair cost details from the Damage Analyst.

3

Claim reporter agent

Purpose: Convert structured JSON output into a human-readable claim report.

Configuration:

• Model: GPT-3.5-turbo (text formatting only for minimal cost)

• Temperature: 0.7

• Max Output Tokens: 1024

System Message:

You are a claim summary reporter and your job is to consolidate the findings about an insurance claim into a human-readable format.

You are going to receive a JSON structure, and you need to provide a report with the following format:

CLAIM REPORT

SUMMARY: <summarized version of the narrative, refer to summary in the JSON structure>

CONSISTENCY CHECKS: <refer to consistency_checks in the JSON structure>

FRAUD ASSESSMENT: <refer to fraud_assessment in the JSON structure>

RECOMMENDATION: <a summary of what the claim agent should do next, refer to recommendation in the JSON structure>

DAMAGE COST ANALYSIS: <a list of all potential parts involved in the incident and an estimate of the costs to repair, refer to cost_estimate in the JSON structure>

User Message:

{{ message.$ }}

Example output:

CLAIM REPORT

SUMMARY:
Maria Silva's Honda Civic was struck by...

CONSISTENCY CHECKS:
No major inconsistencies detected...

FRAUD ASSESSMENT:
Fraud Risk Score: 15/100 (Low Risk)
- Location verified as a legitimate address
- Weather conditions consistent with narrative
- No suspicious patterns detected

RECOMMENDATION:
Approve with conditions...

DAMAGE COST ANALYSIS:
- Door: 1,000 BRL
- Mirror: 2,500 BRL
- Headlights: 3,000 BRL

Total Estimated Cost: 6,500 BRL

4

Format and deliver report

Convert the claim report to the required delivery format and send it to stakeholders.

• Email delivery: Send report to adjusters for review.

• Event to pipeline: Trigger a downstream pipeline for decoupled processing.

• File to bucket: Upload PDF to storage for auditing and archival purposes.

High-fraud path: Complete flow

Claims with a fraud score of 40 or higher skip damage analysis and are sent directly to escalation. This path saves resources by avoiding unnecessary steps for high-risk claims.

1

Claim reporter agent (Fraud alert)

Configuration:

• Model: GPT-3.5-turbo

• Temperature: 0.7

• Max Output Tokens: 1024

System Message:

You are a claim summary reporter and your job is to consolidate the findings about an insurance claim into a human-readable format.

You are going to receive a JSON structure, and you need to provide a report with the following format:

CLAIM REPORT

SUMMARY: <summarized version of the narrative, refer to summary in the JSON structure>

CONSISTENCY CHECKS: <refer to consistency_checks in the JSON structure>

FRAUD ASSESSMENT: <refer to fraud_assessment in the JSON structure>

RECOMMENDATION: <a summary of what the claim agent should do next, refer to recommendation in the JSON structure>

User Message:

{{ message.body }}

2

Format and deliver Report

• Email delivery: Send the fraud alert to adjusters for immediate escalation.

• Event pipeline: Trigger the fraud investigation workflow.

• File to bucket: Archive the report for compliance and pattern analysis.

Extensions

• Store for analytics: Insert claims to a database for fraud pattern analysis.

• Photo analysis: Add an agent to verify whether damaged photos match the narrative description.

• Pattern detection: Query the policyholder's claim history before analysis to identify repeat claims and abuse patterns.

Key takeaways

This how-to guide demonstrates how a multi-agent architecture streamlines insurance claim analysis by combining fraud detection, cost estimation, and structured decision-making in a single, scalable flow.

By separating responsibilities across specialized agents and applying conditional routing, the system improves accuracy while keeping operational costs under control.