实习日志 / Northwind Adaptive FNOL Agent - High-Level Overview

Northwind Adaptive FNOL Agent - High-Level Overview

The Scenario

Northwind Insurance processes more than 80,000 motor, home and contents claims each year. According to the Scenario 8 brief, today's First Notice of Loss (FNOL) process takes 15-25 minutes, 40% of reports require at least one follow-up, and the average time from first report to claim creation is 2.5 days. The contact centre can handle natural conversation and exceptions but is expensive to scale. The web form is faster but long, rigid and difficult to complete after a stressful event.

Scenario 8 asks for a working insurance claims agent that can guide a claimant from their first description of an incident through to claim creation. It must handle multi-turn conversation, photos and PDFs, policy questions, severity and fraud-review signals, claim-system actions, assessor routing and clear next-step communication.

We interpret this as a coordination problem, not simply a chatbot problem. The difficult part is not generating a plausible reply. The difficult part is turning an incomplete and sometimes non-linear account into a reliable claim record, deciding what is needed now, progressing work that is ready, and transferring the case to a person without losing context when professional judgement is required.

Our Core Proposition

Let the claimant explain what happened naturally. The system should handle the insurance structure, evidence tracking and process coordination, and remain responsible for moving the claim to its next safe action.

The claimant should not need to know which form field, team, document or internal status comes next. The Agent should ask only the questions needed for the current decision, explain what is still outstanding, and avoid requesting information that has already been confirmed.

A claim is ready to progress when the available information is sufficient for its next safe action. It does not need every document that may be required later. For example, a police report that has not yet been generated can remain a tracked evidence item while the system continues work that does not depend on it.

The service also keeps three costs visible:

Claimant effort: time, questions, corrections, repeated explanations and uncertainty about the next step.
Staff effort: handoff frequency, time spent reconstructing context, repeated data collection and follow-up work.
Agent cost: model usage, retrieval calls, tool calls, latency, retries and failure handling.

Key Feature 1: Adaptive Claim Intake

The first key feature is an insurance-domain Agent that converts natural conversation into a structured, source-linked claim while adapting to the incident and the claimant's needs.

In practice, this includes:

recognising several needs in one message, such as incident details, an injury concern and a request for human support;
selecting the relevant motor, home, contents, evidence, third-party or support branches instead of forcing every claimant through one questionnaire;
extracting several facts from one answer and recording where each fact came from;
distinguishing claimant statements, document or image evidence, system inference and staff decisions;
asking for confirmation only when a misunderstanding could change a material action;
identifying whether evidence is available, incomplete, unofficial, conflicting, or expected later;
retrieving relevant policy wording or claim history with its source and limitations;
interrupting normal intake for an explicit injury or continuing danger;
arranging a standard or urgent human handoff when support or professional judgement is needed; and
creating and routing a claim when the required facts, authority and current revision are valid.

The Agent does not turn a model response directly into a business action. Its proposed facts and actions pass through server-side validation, permission checks and claim-revision controls. Coverage, fraud, liability, approval and rejection remain professional or controlled business decisions.

Key Feature 2: Shared Claim Coordination

The second key feature is a shared claim context used by the claimant, the Agent and claims staff.

The claimant sees clear progress, outstanding evidence, responsibility and the next step. Claims staff see the same case with the additional operational detail needed to act: confirmed facts, original sources, evidence, conflicts, pending work, handoff reason, internal review signals and communication history.

The Staff Workbench supports operational queues such as urgent work, new or untriaged claims, pending evidence, professional review, ready-to-create claims and created or routed claims. Staff can accept a handoff, review evidence, record a decision, complete an action and send an appropriate update back to the claimant.

This shared context solves a common failure in claim handling: the claimant should not need to repeat the incident because work moved from an automated channel to a person. A handoff should tell staff what is already known, where it came from, what remains uncertain and exactly what action is required.

The same approach can later extend to approved assessors, repairers and other service participants. Each participant receives only the information needed for an authorised task, while the claim retains one visible record of responsibility, status and outcome.

How a Claim Moves Through the Product

Start or resume: the claimant starts a new report or returns to an existing claim and continues from the latest saved state.
Describe the incident: the claimant explains what happened in their own words and may add images or documents.
Structure the claim: the Agent updates the internal form, records sources and identifies material gaps or conflicts.
Choose the next action: the system asks a focused question, requests confirmation, retrieves supporting information, progresses the claim, or creates a handoff.
Track unfinished work: missing evidence, professional review and external requests remain explicit tasks with an owner and status instead of becoming a vague blocked claim.
Create and route: once the current requirements and authority checks pass, the claim is created and routed through the configured claims service.
Continue across channels: the claimant and staff continue from the same claim state, with appropriate information shown to each role.

Technology at a Glance

Customer and staff interfaces

React and Vite claimant application: natural-language intake, claim progress, form corrections, evidence submission, resume, human support and claim-creation results.
Browser-based Staff Workbench: operational queues, claim detail, evidence and source review, assignments, handoffs, professional-review actions and claimant communication.

Backend and APIs

Python 3.12 and FastAPI: versioned APIs for claims, sessions, messages, forms, evidence, support requests, handoffs, staff actions, claim creation, assessor routing, retrieval and operational status.
Pydantic domain models: shared request, response and Claim State structures used across backend services and tests.
Service and adapter boundaries: claim behaviour is separated from databases, object storage, model providers and external claims services so those integrations can change without rewriting the product flow.

Agent and model layer

Agent behaviour rules and catalogue: document the trigger, required result, prohibited result, allowed tools, authority and test evidence for each supported journey.
Intent and branch handling: identifies urgent, support, clarification, confirmation, evidence, resume, review and claim-progression needs, including several needs in one message.
Model Gateway: gives the Agent one structured interface for calling different language-model endpoints and normalises their outputs, usage and errors.
Field, action and tool registries: the current Field Registry limits the form fields the Agent may propose; the action and tool registries are being added to apply the same control to business actions and integrations.
Controlled execution: separates what the model proposes from what the server validates and what the system actually completes.

Data, evidence and retrieval

Shared Claim State: the current claim facts, evidence status, workflow, responsibility and next action are maintained as one authoritative record.
Session and message persistence: preserves conversation history and supports returning to a claim without restarting.
MongoDB persistence foundation: implements repository mappings and transaction-oriented claim updates for the persistent runtime path.
MinIO and S3-compatible object storage: stores evidence files separately from claim records while retaining provenance and protected references.
RAG ingestion and retrieval: prepares approved documents, stores source metadata and retrieves relevant passages with citations.
Policy and claim-history services: return structured, source-linked information for explanations and professional review.

Delivery and quality

GitHub repository and Project board: Issues and pull requests track implementation, while Kanban automation follows work from planning through review and completion.
CircleCI and repository quality gates: provide the remote execution path for backend formatting, linting, type checks, tests and coverage, frontend linting, tests and production builds, automation checks and pull-request policy checks.
Repeatable fixtures: exercise complete claimant, Agent, evidence, handoff, resume, claim-creation, assessor and staff-workbench paths with known inputs and observable state changes.

Delivery Progress

Working end-to-end foundation

The project already has a connected claimant application, FastAPI backend and Staff Workbench. A claimant can create or resume a report, send messages, update and confirm structured information, register evidence, request human support and progress a controlled claim-creation journey. Staff can inspect the same claim, work from operational queues, accept handoffs, record actions and send claimant-visible updates.

Claim, session, message, evidence, handoff and staff-action data use shared identifiers, revision checks and ownership rules. Repeatable scenarios cover clear claims, professional review, urgent escalation, human requests, pending evidence, cross-session resume, history-supported review signals, claim creation and assessor interaction.

MVP capabilities being connected

Current work is moving from controlled Agent decisions to a fuller model-backed Agent Runtime. The main areas are:

richer intent recognition and branch selection from one claimant message;
registered Agent actions and tools with explicit authority and visibility;
a complete proposal, validation, execution and result record for each Agent turn;
model-provider configuration for local, compatible API and cloud endpoints;
metadata-filtered RAG with source-version and citation checks;
completion of the persistent MongoDB runtime profile;
broader claim-family and field coverage beyond the current bounded intake path; and
stronger staff @Agent assistance for claim summaries, evidence comparison and next-step preparation.

Provider and deployment progression

The application currently runs its repeatable demonstration through a complete fixture profile, with MinIO available for S3-compatible evidence storage. MongoDB, cloud data services and model endpoints are connected through the same application interfaces as their implementations are verified. AWS work focuses on mapping those existing interfaces to approved AWS services and deploying the same application behaviour without creating a separate AWS-specific product path.

Product Goals

The product is successful when it produces a claim that another person or system can continue processing without reconstructing the intake. That means:

known facts are structured and linked to their sources;
important uncertainty and conflicting evidence remain visible;
outstanding evidence and professional decisions have a clear owner and status;
the claimant understands what has happened and what comes next;
human support receives enough context to continue without repeating confirmed questions;
safe work continues while unrelated later evidence remains pending;
claim creation and external actions are revision-safe and idempotent; and
model, retrieval and tool costs can be compared with the claimant and staff effort they save.

Acceptance Standard

Scenario 8 challenge acceptance

The final proof covers ten end-to-end scenarios: five motor, three home and two contents. Each scenario begins with the claimant's report and ends with a created claim, route, claim number and expected next step.

The challenge measures:

at least 80% of scenarios completed without follow-up information;
severity classification accuracy assessed through blind review by claims staff;
no false-positive fraud flags in the test set; and
a claimant role-play completed in under five minutes and fewer than ten questions.

Product acceptance

For the team, a successful final answer is not enough. A scenario passes only when the complete path can be repeated and inspected:

claimant input changes the structured claim and persists the correct source;
images and documents enter a visible evidence lifecycle;
pending evidence does not block an unrelated safe action;
correction and confirmation update the claim without erasing history;
resume restores the latest claim, unresolved work and prior commitment;
urgent and human-support paths create the correct handoff with context;
policy, history and knowledge answers retain supporting sources;
internal review signals remain visible to staff and hidden from claimants;
staff decisions write back to the same claim and create an appropriate claimant update;
retries do not create duplicate claims, messages, handoffs or external requests; and
dependency failure preserves accepted progress and gives the claimant or staff a usable next step.

Project Links

Claimant demo: https://demo.ysoseri.us/
Staff Workbench: https://demo.ysoseri.us/employee/