AgentKits

Insurance Claims Intake & Triage Agent

Production Blueprint
0New

Includes Agent Blueprint + Implementation Guide

An agent that handles the first stage of an insurance claim: it validates that the first notice of loss is complete, classifies the claim type and severity, screens coverage administratively, flags potential fraud indicators for SIU, and routes the claim to the right queue — fast-track, complex, or special investigations. It is built for a regulated setting: it is administrative triage only, it does not make coverage determinations or decide liability, it flags fraud indicators rather than accusing, it grounds every decision in policy and claim data, and it escalates injury, large, or ambiguous claims to a human adjuster.

insuranceclaimsfnoltriageinsurtechfraud-detectionautonomous-agentintakeagentazagent-governancetrust-levelproduction-readiness
StackClaude, LangGraph, OpenAI
DifficultyAdvanced
Setup50 min
Version2.0.0 · 2026-06-21

Overview

Intake → validate → classify → screen → route: turns a first notice of loss into a complete, correctly-routed claim.

Administrative only: it checks completeness and coverage applicability and routes — it does not approve, deny, or decide liability.

Catches gaps and fraud signals early: missing documents are requested precisely, and fraud indicators are flagged for SIU as indicators, not accusations.

Escalates by design: injury, large-value, or ambiguous claims go to a human adjuster with the context.

AgentAz™ specification

A lightweight, design-time governance spec for security review. It documents what this agent is authorized to do — and why — and pairs with whatever policy engine you already run. It does not enforce anything at runtime.

Trust Level ?A2 — Recommend
DNA PatternExtraction (Extract → Verify)
Worst-Case ActionMisclassifies or misroutes a claim, surfaced for human review. It cannot approve, deny, adjust, or pay a claim — execution tools are absent from its registry.
Authority BoundaryIntakes a claim, extracts structured data, and triages and routes it for human handling. It never approves, denies, or pays a claim. An adjuster makes every determination.
Verification TestAttempt to call an approve, deny, or payment tool → confirm it is absent from the agent's registry.
Production Readiness6/6 dimensions passing. Tool isolation: decision/payment tools absent. Human gates: an adjuster decides. Confidence escalation: low-confidence extractions flagged. Cost ceiling: bounded. Audit trail: extraction and routing logged. Escalation path: complex claims routed to a senior adjuster.
Last Reviewed2026-06-24

Machine-readable contract (agentaz.json), validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL:

agentaz.json
{
  "$schema": "./agentaz.schema.json",
  "version": "2.0.0",
  "last_reviewed": "2026-06-24",
  "agent_id": "claims-intake-triage-agent",
  "trust_level": "A2",
  "dna_pattern": "Extraction",
  "worst_case_action": "Misroutes a claim, surfaced for human review. Cannot approve, deny, or pay claims.",
  "authority_boundary": "Extracts claim data and triages/routes for human handling; decision/payment tools absent.",
  "tags": [
    "insurance",
    "claims",
    "intake",
    "read-only",
    "human-review"
  ],
  "tool_boundary": {
    "allowed_tools": [
      "read_claim",
      "extract_fields",
      "validate_schema",
      "classify",
      "route"
    ],
    "execution_tools_absent": true
  },
  "output_boundary": {
    "format": "structured_json",
    "never_emits": [
      "claim_approve",
      "claim_deny",
      "payment"
    ]
  },
  "cost_boundary": {
    "max_usd_per_trace_loop": 0.25,
    "alert_threshold_usd": 0.16
  },
  "loop_boundary": {
    "max_reasoning_turns": 8
  },
  "human_handoff": {
    "triggers": [
      "low_confidence_extraction",
      "complex_claim",
      "missing_data"
    ],
    "destination": "adjuster_queue"
  },
  "audit": {
    "append_only": true,
    "logs": [
      "extraction",
      "classification",
      "routing"
    ]
  }
}

New to this? Read the AgentAz specification guide — Trust Levels, DNA patterns, and how it complements your runtime.

AgentAz™ is open source under Apache-2.0 — schema (frozen v1.0.0) and source on GitHub.

Governance matrix

A scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality.

Agent goalBounded by the authority spec above
Trust LevelA2 — Recommend
Tool accessLeast privilege — execution tools absent (read-only)
Context handlingGrounded in provided inputs; cites or flags rather than guessing
Memory strategyTask-scoped; no persistent cross-session memory
Human approvalRequired on low confidence extraction, complex claim, missing data → adjuster queue
Audit trailAppend-only log (extraction, classification, routing)
Cost & loop bounds≤ $0.25 per loop · ≤ 8 reasoning turns
Recovery / escalationEscalates to adjuster queue

Agent component mapping

A framework-neutral view of how this blueprint maps to standard agent-architecture components (the vocabulary common to ADK-style frameworks). It describes structure for clarity — not an official integration or certified compatibility.

AgentPrimary reasoner — Recommend authority (A2)
Toolsread claim, extract fields, validate schema, classify, route — execution tools absent (read-only)
MemoryTask-scoped working context; no persistent cross-session memory
GuardrailsWorst-case classified (A2); no execution tools; ≤ $0.25/loop · ≤ 8 turns
EvaluatorConfidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned
HandoffEscalates to adjuster queue on low confidence extraction, complex claim, missing data

Failure modes

Specific ways this blueprint can fail, and how it is designed to detect, contain, and recover from each — the boundaries that make it safe to run, stated plainly.

Mis-prioritizes a severe claim as routine.

Detection
Severity is scored against documented criteria and uncertain cases are flagged.
Mitigation
It triages only — never closes or denies — and high severity is always surfaced.
Recovery
An adjuster re-prioritizes and the rule is tuned.

Extracts a wrong claim detail such as date of loss or amount.

Detection
Extracted fields cite the source and low confidence is flagged.
Mitigation
Fields feed a human, not an automated decision.
Recovery
The adjuster corrects the detail before processing.

Misses a fraud indicator.

Detection
Known indicator checks run and the agent flags rather than clears.
Mitigation
Suspected indicators are routed to the investigations unit.
Recovery
The indicator set is expanded after review.

Evaluation

Severity-prioritization accuracy and fraud-indicator recall are primary — mis-ranking a severe claim or missing a fraud flag is the failure.

Prioritization accuracyShare of claims assigned the correct severity or priority versus an adjuster.
Fraud-indicator recallOf claims with known indicators, the share it flags.
Extraction accuracyAccuracy of extracted claim details such as date of loss and amount.
Escalation rateHow often severe or uncertain claims are correctly surfaced.
LatencyTime to triage a claim.

Recommended approach. Replay historical claims with adjuster-assigned priorities and known fraud indicators; measure prioritization accuracy and indicator recall. Verify it never closes or denies — triage only.

When to use

Use it when

  • You process high claim volume and intake/triage (completeness, classification, routing) consumes adjuster time.
  • You have policy data and routing rules, and access to claim/FNOL details.
  • You want consistent, documented triage with early fraud-indicator flagging and accurate routing.
  • You want to fast-track simple complete claims and route complex, injury, or suspicious ones to the right humans.

Avoid it when

  • You expect it to determine coverage, decide liability, or approve/deny claims — those are adjuster/insurer decisions it must never make.
  • You can't provide policy and claim data for grounded triage.
  • The claim clearly needs a human from the start (serious injury, litigation).
  • You can't support regulatory/PII handling of claimant data.

System prompt

system-prompt.md
You are an Insurance Claims Intake & Triage Agent. Your job is administrative: take a first notice of loss (FNOL), make sure it is complete, classify and route it, and screen coverage applicability for routing purposes. You do NOT adjudicate. You never determine coverage, decide liability, or approve/deny a claim. You are judged on complete, correctly-routed intake, early and fair fraud-indicator flagging, and never overstepping into adjudication.

== ABSOLUTE BOUNDARIES (NON-NEGOTIABLE) ==
- NO ADJUDICATION. You never approve, deny, or recommend approval/denial of a claim, never determine that a loss is or isn't covered, and never decide liability or fault. Coverage 'screening' here is administrative (is the policy active? is this peril the kind the policy lists?) to ROUTE the claim — not a coverage determination.
- FRAUD = INDICATORS, NOT ACCUSATIONS. If you detect potential fraud indicators, flag them for SIU (Special Investigations) with the evidence. Never assert that a claimant committed fraud. Most flags have innocent explanations.
- ESCALATE THE SERIOUS. Bodily injury, fatalities, large/complex losses, litigation, or ambiguous facts go to a human adjuster — do not fast-track them.
- GROUNDED & NO FABRICATION. Base everything on the policy and claim data provided; cite it. Never invent facts, coverage, or a police report that isn't there. Missing info is requested, not assumed.
- PII / REGULATORY. Treat claimant data as sensitive PII; keep it in scope; follow fair-claims-handling norms and treat claimants neutrally.

== METHOD ==
- Validate completeness against the FNOL checklist for the claim type (e.g. date/location of loss, description, photos, police/incident report where required, third-party info).
- Classify claim type and a severity/complexity level.
- Administratively screen coverage for routing: is the policy active on the loss date, and is the reported peril within the policy's listed perils? (Routing signal only — not a coverage decision.)
- Scan for fraud indicators (late reporting, inconsistent details, prior pattern, staged-loss markers) as indicators for SIU.
- Route to the correct queue and request any missing information.

== DECISION POLICY ==
- FAST_TRACK: simple, complete, low-severity claim with policy active and peril plainly within scope. Route to the fast-track queue (still adjuster-owned).
- ROUTE_STANDARD: complete but standard-complexity → standard adjuster queue.
- REQUEST_INFO: incomplete → list exactly what's missing and hold.
- ESCALATE: injury/fatality, large/complex/ambiguous loss, possible non-coverage situation, or fraud indicators → senior adjuster and/or SIU.

== OUTPUT FORMAT (return ONE JSON object) ==
{
  "claim_id": "<id>",
  "claim_type": "<auto|property|liability|...>",
  "severity": "low|moderate|high",
  "completeness": "complete|incomplete",
  "missing": ["<exact items needed, or empty>"],
  "coverage_screen": "policy_active_and_peril_listed|policy_inactive|peril_not_listed|unclear (ADMINISTRATIVE routing signal only, NOT a determination)",
  "fraud_indicators": ["<evidence-based indicator for SIU, or empty>"],
  "decision": "FAST_TRACK|ROUTE_STANDARD|REQUEST_INFO|ESCALATE",
  "route_to": "<queue: fast_track|standard|senior_adjuster|SIU>",
  "claimant_note": "<neutral, supportive; no coverage promise or denial>",
  "escalation": { "needed": <bool>, "to": "adjuster|SIU|none", "reason": "<why, or empty>" },
  "disclaimer": "Administrative intake & routing only — not a coverage, liability, or claim decision."
}
Never output a coverage or liability decision. If injury, large loss, ambiguity, or fraud indicators are present, ESCALATE.
Was this useful?

Simulate run

Try the agent with a sample task. This is a frontend-only preview that shows how the kit would plan and execute — no API calls, nothing leaves your browser.

Frontend preview only — no data leaves your browser. Tip: press ⌘/Ctrl + Enter to run.

Setup guide

Install and connect claims systems

Install the agent and connect it to your claims/policy systems under appropriate access.

shell
pipx install claims-triage-agent
claims-triage-agent connect --claims guidewire --policy core
claims-triage-agent doctor   # checks PII handling + audit logging

Configure boundaries and routing

Lock the agent to administrative triage. Adjudication is impossible by config.

shell
cp .env.example .env
ANTHROPIC_API_KEY=sk-ant-...
ADJUDICATION=false        # never approves/denies or decides coverage
ESCALATE: ["bodily_injury", "fatality", "large_loss", "litigation", "fraud_indicator"]
SIU_QUEUE=special_investigations

Define FNOL checklists & routing rules

Provide the required-items checklist per claim type and the queue routing rules.

shell
# claims.yml
auto_glass: { required: [date, location, photos, policy_number], severity: low }
theft: { required: [date, location, police_report, item_list], severity: moderate }
bodily_injury: { always_escalate: true }

Dry-run on past FNOLs

Replay historical claims to check classification and routing before going live.

shell
claims-triage-agent backtest --range 60d --explain
# reports completeness/classification/routing accuracy and any mis-routes

Wire into intake

Route new FNOLs to the agent for triage; injury/large/fraud cases auto-route to humans/SIU.

shell
# FNOL channel -> POST https://your-host/claims/intake (HMAC)
# decision=ESCALATE auto-assigns to senior adjuster / SIU

Architecture

Tools required

get_claimRetrieve the FNOL: claimant, policy number, date/location of loss, description, and attachments.
policy_lookupReturn policy status (active on the loss date), coverage type, and the listed perils for administrative screening.
completeness_checkValidate the claim against the FNOL checklist for its type and list missing required items.
coverage_screenAdministratively check policy-active and peril-listed status as a routing signal (not a coverage determination).
fraud_indicator_scanDetect evidence-based fraud indicators (late report, inconsistencies, prior patterns) to flag for SIU.
severity_classifyClassify claim type and severity/complexity to drive routing.
route_to_queueRoute the claim to the correct queue (fast-track, standard, senior adjuster, SIU).
escalate_to_adjusterEscalate injury/large/ambiguous claims and SIU referrals to the appropriate human with context.

Workflow

  1. 1. Intake the FNOL

    Normalize the claimant, policy, loss details, and attachments into a structured claim.

  2. 2. Validate completeness

    Check against the FNOL checklist for the claim type and list exactly what's missing.

  3. 3. Classify

    Determine claim type and severity/complexity to drive routing, without judging the merits.

  4. 4. Screen coverage (administratively)

    Check policy active-on-date and whether the peril is listed — a routing signal only, never a coverage decision.

  5. 5. Scan for fraud indicators

    Surface evidence-based indicators for SIU as indicators, not accusations, with innocent explanations possible.

  6. 6. Route or request info

    Fast-track simple complete claims, route standard ones, request missing info, and escalate injury/large/ambiguous/fraud cases to humans.

  7. 7. Acknowledge & log

    Send a neutral acknowledgement, request any missing items, and log the triage with cited data for regulatory audit.

Examples

Simple complete auto-glass claim → fast-track

A low-severity windshield claim with everything attached and an active policy listing the peril. Routes to fast-track (still adjuster-owned).

Input

input
FNOL CLM-7781: windshield crack, policy active, comprehensive coverage. Provided: date, location, photos, policy number. No injuries.

Output

output
{
  "claim_id": "CLM-7781",
  "claim_type": "auto_glass",
  "severity": "low",
  "completeness": "complete",
  "missing": [],
  "coverage_screen": "policy_active_and_peril_listed",
  "fraud_indicators": [],
  "decision": "FAST_TRACK",
  "route_to": "fast_track",
  "claimant_note": "Thanks for reporting your windshield damage. Your claim CLM-7781 is complete and has been sent to our fast-track team; they'll be in touch with next steps.",
  "escalation": { "needed": false, "to": "none", "reason": "" },
  "disclaimer": "Administrative intake & routing only — not a coverage, liability, or claim decision."
}

Note: Note the careful coverage language: 'policy_active_and_peril_listed' is an administrative routing signal, and the claimant note promises next steps, not approval. Complete + low-severity + peril listed → fast-track queue, where a human still owns the claim.

Theft claim missing the police report → request info, hold

A theft claim is missing a required document. The agent requests exactly what's needed instead of routing an incomplete claim.

Input

input
FNOL CLM-7820: laptop theft from vehicle. Provided: date, location, item list, policy number. Missing: police report (required for theft).

Output

output
{
  "claim_id": "CLM-7820",
  "claim_type": "theft",
  "severity": "moderate",
  "completeness": "incomplete",
  "missing": ["Police/incident report number (required for theft claims)"],
  "coverage_screen": "policy_active_and_peril_listed",
  "fraud_indicators": [],
  "decision": "REQUEST_INFO",
  "route_to": "standard",
  "claimant_note": "Thanks for reporting the theft (CLM-7820). To proceed we need the police report or incident number for the theft. Once you add it, we'll continue processing your claim.",
  "escalation": { "needed": false, "to": "none", "reason": "" },
  "disclaimer": "Administrative intake & routing only — not a coverage, liability, or claim decision."
}

Note: Rather than routing an incomplete claim (which stalls later) or assuming the report exists, the agent names the exact missing item, holds, and asks the claimant for it in neutral language. Precise gap-chasing is the core intake time-saver.

Injury + fraud indicators → escalate to adjuster & SIU, no decision

A claim involves bodily injury, was reported late, and has inconsistencies plus a prior pattern. The agent escalates and flags indicators — without deciding coverage or accusing anyone.

Input

input
FNOL CLM-7905: auto accident with claimed neck injury. Reported 28 days after the loss; the described damage is inconsistent with the photos; claimant has 3 similar soft-tissue claims in 18 months.

Output

output
{
  "claim_id": "CLM-7905",
  "claim_type": "auto_bodily_injury",
  "severity": "high",
  "completeness": "complete",
  "missing": [],
  "coverage_screen": "policy_active_and_peril_listed",
  "fraud_indicators": ["Reported 28 days post-loss (late)", "Described damage inconsistent with submitted photos", "3 similar soft-tissue claims in 18 months"],
  "decision": "ESCALATE",
  "route_to": "senior_adjuster",
  "claimant_note": "Thank you for reporting your claim (CLM-7905). It has been assigned to an adjuster who will review the details and contact you.",
  "escalation": { "needed": true, "to": "SIU", "reason": "Bodily injury claim with fraud indicators (late report, photo inconsistency, prior pattern) — for senior adjuster review and SIU evaluation of the indicators." },
  "disclaimer": "Administrative intake & routing only — not a coverage, liability, or claim decision."
}

Note: The defining boundary case: bodily injury alone forces escalation, and the fraud indicators are listed as indicators for SIU to evaluate — not as an accusation. The agent makes no coverage or liability decision, keeps the claimant note neutral and supportive, and routes to both a senior adjuster and SIU. Exactly the line an administrative triage agent must hold.

Implementation notes

  • Lock 'no adjudication' in configuration and the prompt: the agent never approves, denies, or decides coverage/liability. 'Coverage screening' is strictly an administrative routing signal.
  • Treat fraud detection as indicator-flagging for SIU with evidence, never as accusation — most indicators have innocent explanations and fair-claims handling requires neutrality.
  • Force escalation for bodily injury, fatalities, large/complex/ambiguous losses, and litigation; these must never be fast-tracked.
  • Request missing information precisely against a per-claim-type checklist; routing incomplete claims or assuming missing facts causes downstream delays and unfairness.
  • Keep claimant communications neutral and supportive — never imply approval or denial during intake.
  • Handle claimant data as regulated PII, keep it in scope, and log triage decisions with cited data for fair-claims and regulatory audit.
  • A cheaper model is usually enough to validate completeness and classify, so keep the strong model for ambiguity, fraud-indicator judgment, and escalation framing.

Variations

Basic

Intake & completeness assistant

Validates FNOL completeness, classifies the claim, and suggests a route for an adjuster. Administrative only — no coverage screening or auto-routing.

Advanced

Triage & routing with fraud flags

Adds administrative coverage screening, fraud-indicator flagging for SIU, severity-based routing, and missing-info requests — with mandatory escalation for injury/large/ambiguous claims.

Enterprise

Governed claims intake

Adds claims-system integration, multi-line FNOL checklists, SIU workflows, full regulatory audit trails and fair-claims controls, and routing tuning from outcomes — humans retain all claim decisions.

Download the Agent Blueprint

The complete blueprint, zipped — including a runnable run.py you can execute with one API key (Anthropic or OpenAI).

Download Blueprint (.zip)
README.mdsystem-prompt.mdsetup-guide.mdtools.jsonworkflow.mdexamples.md.env.examplekit.jsonrun.pyLICENSENOTICEstarters/

Export

Generate a starter for your stack — all client-side, nothing leaves your browser.

ZIP

Starters use mock tools — swap in your integrations to deploy.

View the source on GitHub

This blueprint and the AgentAz™ specification live in the central AgentKits registry — open source under Apache-2.0 (code & schema) and CC‑BY‑4.0 (text).

Frequently asked questions