Case Study: Claims Intake Automation (FNOL)
This is a worked example of the FNOL (First Notice of Loss) pipeline as it exists in the repository today — the product specification, the packaged agents, and what actually runs end-to-end. It is written for a South African Personal Lines Auto carrier design partner, per FNOL-WORKFLOW.md.
The pipeline as specified
This maps to six named agent packages, wired together as packages/workflows/claims/fnol-claims-pipeline:
| Phase | Agent | What it does |
|---|---|---|
| 1 — Intake & Notification | fnol-intake-agent | Extracts ACORD-standard + SA-specific fields from the raw report, resolves the policy (policy.lookup), opens a claim draft (claim.create), and acknowledges the reporter (notify_send_sms/email/WhatsApp) |
| 2 — Validation & Enrichment | fnol-validation-agent | Confirms the policy was in force at the date of loss, checks coverage and excess, matches the vehicle on risk, confirms the insured's identity, and pulls prior-claims history |
| 3a — Fraud Signalling | fnol-fraud-signal-agent | Emits structured, weighted fraud signals with evidence — never a fraud determination (see fraud-detection.md) |
| 3b — Severity Scoring | fnol-severity-agent | Assigns a 1–5 severity score against SA rand value bands, with escalating factors (injury, fatality, violence, total loss) that can override the rand band |
| 4 — Severity Routing Decision | fnol-routing-agent | Chooses Track A (straight-through processing), Track B (standard adjudication), or Track C (complex/SIU) based on severity, fraud signals, and coverage position |
| 5 — Resolution & Closure | fnol-resolution-agent | Auto-resolves Track A claims; for Track B/C, mints the claim number and hands off to the assigned human |
Every step is regulatory-posture-constrained by design: agents produce signals and recommendations, never autonomous fraud, coverage, or repudiation determinations (FAIS Act). PII is tokenized before Phase 2 and only re-hydrated for the reporter-facing notification steps.
What actually runs today
The real 6-agent pipeline is installed and wired, but currently fails partway through Phase 3b (severity scoring) — tracked as Issue #589. Phases 1, 2, and 3a execute against the pipeline's own agent packages and prompts as designed; the pipeline does not currently complete through to Phase 5 resolution in an automated run.
A simplified 4-step, single-agent stand-in workflow (verify-policy → create-claim-draft → confirm-claim → notify-policyholder) proves the underlying mechanism end-to-end: an inbound FNOL notice arrives over a webhook channel, Hoziron resolves it to the workflow by name, and a real cloud-routed LLM extracts structured fields from unstructured FNOL prose, calls policy-lookup and claim-creation tools, and sends a confirmation SMS — the autonomous trigger → real-reasoning → claim-minted → notify chain works mechanically, using a simplified single-agent workflow rather than the full 6-agent regulatory pipeline.
Why this matters for a design partner
- The product spec (six phases, human handoff matrix, PII boundary, audit event schema) is fully documented in FNOL-WORKFLOW.md and is what engineering builds against.
- The six agent packages, their competencies, and the pipeline's
agents_requireddependency graph already exist on disk and install via the catalog's transitive-install resolution — they are not vaporware, they are blocked on one specific defect (Phase 3b) rather than unbuilt. - The
--reduceddemo is a legitimate way to see the autonomous trigger mechanism (testbed → webhook → workflow resolution → real multi-step LLM tool-calling → claim minted) working today, while the real pipeline's remaining defect is fixed.
The FNOL spec's own "Phase 1 → Phase 2 Boundary" section notes PII tokenization/hydration as deferred work for this specific workflow's prompt-level instructions — in the current codebase, deny-by-default PII tokenization is implemented at the platform layer independent of any one workflow (see ADR-027 and ADR-049 in the decisions/ directory), so the platform-level protection applies to this pipeline regardless of that workflow-specific gap.
Related: