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.
Machine-readable contract (agentaz.json), validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL:
{
"$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 goal | Bounded by the authority spec above |
|---|---|
| Trust Level | A2 — Recommend |
| Tool access | Least privilege — execution tools absent (read-only) |
| Context handling | Grounded in provided inputs; cites or flags rather than guessing |
| Memory strategy | Task-scoped; no persistent cross-session memory |
| Human approval | Required on low confidence extraction, complex claim, missing data → adjuster queue |
| Audit trail | Append-only log (extraction, classification, routing) |
| Cost & loop bounds | ≤ $0.25 per loop · ≤ 8 reasoning turns |
| Recovery / escalation | Escalates 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.
| Agent | Primary reasoner — Recommend authority (A2) |
|---|---|
| Tools | read claim, extract fields, validate schema, classify, route — execution tools absent (read-only) |
| Memory | Task-scoped working context; no persistent cross-session memory |
| Guardrails | Worst-case classified (A2); no execution tools; ≤ $0.25/loop · ≤ 8 turns |
| Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned |
| Handoff | Escalates 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 accuracy | Share of claims assigned the correct severity or priority versus an adjuster. |
|---|---|
| Fraud-indicator recall | Of claims with known indicators, the share it flags. |
| Extraction accuracy | Accuracy of extracted claim details such as date of loss and amount. |
| Escalation rate | How often severe or uncertain claims are correctly surfaced. |
| Latency | Time 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
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.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.
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.
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.
# 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.
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.
# FNOL channel -> POST https://your-host/claims/intake (HMAC) # decision=ESCALATE auto-assigns to senior adjuster / SIU
Architecture
Tools required
Workflow
1. Intake the FNOL
Normalize the claimant, policy, loss details, and attachments into a structured claim.
2. Validate completeness
Check against the FNOL checklist for the claim type and list exactly what's missing.
3. Classify
Determine claim type and severity/complexity to drive routing, without judging the merits.
4. Screen coverage (administratively)
Check policy active-on-date and whether the peril is listed — a routing signal only, never a coverage decision.
5. Scan for fraud indicators
Surface evidence-based indicators for SIU as indicators, not accusations, with innocent explanations possible.
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. 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
FNOL CLM-7781: windshield crack, policy active, comprehensive coverage. Provided: date, location, photos, policy number. No injuries.
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
FNOL CLM-7820: laptop theft from vehicle. Provided: date, location, item list, policy number. Missing: police report (required for theft).
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
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
{
"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
Export
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
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.
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.
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.
Bodily injury, fatalities, large or complex losses, litigation, and ambiguous facts are always escalated to a human adjuster and never fast-tracked.
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.
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.