# Insurance Claims Intake & Triage Agent

> An administrative claims-intake agent: validates FNOL completeness, screens coverage, flags fraud indicators for SIU, and routes. No coverage decisions.

- **Category:** Insurance
- **Difficulty:** Advanced
- **Setup time:** 50 min
- **Stacks:** Claude, LangGraph, OpenAI
- **Version:** 2.0.0 (updated 2026-06-21)
- **Source:** https://agent-kits.com/kit/claims-intake-triager

## 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.

## When to use it

- 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.

## When not to use it

- 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.

## Architecture

- **FNOL intake** — Receives the first notice of loss (claimant, policy number, date/location, description, attachments) from the channel and normalizes it into a structured claim.
- **Completeness validation** — Checks the claim against the FNOL checklist for its type and identifies exactly which required items are missing.
- **Classification** — Determines claim type and a severity/complexity level to drive routing — without judging the merits of the claim.
- **Administrative coverage screen** — Checks policy active-on-date and whether the reported peril is among the policy's listed perils — a routing signal only, explicitly not a coverage determination.
- **Fraud-indicator scan** — Surfaces evidence-based indicators (late reporting, inconsistencies, prior patterns) for SIU as indicators, never as accusations.
- **Routing & escalation gate** — A deterministic gate routes injury/large/ambiguous claims and fraud-indicator cases to humans/SIU and never fast-tracks them.
- **Comms & audit** — Requests missing info, sends a neutral acknowledgement, and logs the triage with cited data for regulatory auditability.

## Files in this bundle

- `system-prompt.md` — the agent's system prompt
- `tools.json` — tool/function definitions the agent expects
- `workflow.md` — step-by-step run loop
- `.env.example` — environment variables to fill in
- `kit.json` — full structured metadata
- `starters/` — minimal starter snippets
- `LICENSE` — Apache-2.0 (code, configuration, and schema)
- `LICENSE-CONTENT` — CC BY 4.0 (specification text and documentation)
- `NOTICE` — attribution and trademark notice
- `run.py` — **runnable demo**: real agent loop with mock tools (`pip install anthropic`, set `ANTHROPIC_API_KEY`, `python run.py`)
- `agentaz.json` / `agentaz.schema.json` — AgentAz™ governance spec + schema

## 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.

## FAQ

**Does it approve or deny claims?**

No. It performs administrative intake and triage only — validating completeness, classifying, screening coverage for routing, and routing to the right queue. It never approves, denies, or determines coverage or liability; a human adjuster does.

**What does 'coverage screening' mean if it isn't a decision?**

It's an administrative routing signal — checking whether the policy was active on the loss date and whether the reported peril is among the policy's listed perils. It informs routing, not adjudication, and every output says so.

**How does it handle suspected fraud?**

It flags evidence-based fraud indicators (late reporting, inconsistencies, prior patterns) for your SIU team to evaluate — as indicators, not accusations, since most have innocent explanations. It never asserts a claimant committed fraud.

**What about injury or serious claims?**

Bodily injury, fatalities, large or complex losses, litigation, and ambiguous facts are always escalated to a human adjuster and never fast-tracked.

**What happens when a claim is incomplete?**

It lists exactly what's missing against the FNOL checklist for that claim type, holds the claim, and asks the claimant for the specific items in neutral language — rather than routing an incomplete claim or assuming facts.

**Is claimant data handled appropriately?**

Yes. It treats claimant information as regulated PII, keeps it in scope, follows fair-claims-handling norms with neutral communications, and logs triage decisions with cited data for audit.


---

© 2026 AgentKits · www.agent-kits.com

**Open source.** Code, configuration, and the AgentAz™ schema are licensed under
**Apache-2.0**; specification text and documentation under **CC BY 4.0** (with
attribution to AgentKits, link to https://www.agent-kits.com). See LICENSE, LICENSE-CONTENT,
and NOTICE in this bundle. "AgentAz" and "AgentKits" are trademarks of AgentKits.

**Flagship reference blueprint.** View the source, AgentAz™ spec, and frozen v1.0 schema
in the public registry: https://github.com/agent-kits/agentaz
Original: https://agent-kits.com/kit/claims-intake-triager
