The Claim Intake Loop: Designing Agentic FNOL Systems That Keep Humans in Charge

Claim intake is the worst possible place to be slow. It is the first conversation a policyholder has after something has already gone wrong, and it is the biggest lever a carrier has on loss cost, cycle time and retention. Yet in most organisations, First Notice of Loss still runs on intake forms, PDFs, phone scripts and an adjuster's inbox. It is manual where it should be systematic, and rigid where it should flex.

Software teams working with coding agents have converged on a pattern called loop engineering. Rather than prompting an assistant turn by turn, you design a system of triggered automations, isolated workspaces, codified knowledge, tool connectors and a maker/checker split, and that system prompts the agent for you. The same shape maps onto claim intake with one important difference: in claims, the checker is not always another model. Above a certain threshold it has to be a licensed adjuster, because the cost of being confidently wrong is a regulatory complaint, a wrongly denied claim, or a payout that should never have gone out.

Why claim intake is a loop, not a chatbot

Most carriers start with a chat-based FNOL assistant: the policyholder talks, a model extracts fields, a form fills faster. Useful, but it is still a human holding the tool for one turn, and it does nothing about what happens after the report is filed. The document chasing, the coverage checks, the fraud triage, the sixteen follow-up emails asking for a police report that never arrives.

A loop fits because claim intake is not one task. It is a recurring, multi-step process with a clear terminal condition: the claim is either ready for an adjuster decision or blocked on something specific. Define that goal once, and let the system iterate toward it instead of a person babysitting each step.

Mapping the primitives to claims

Primitive	In a coding loop	In a claims loop
Trigger	Scheduled automations	Event-driven: FNOL submitted, document uploaded, SLA timer about to breach
Isolation	Worktrees per agent	A per-claim workspace, so claim #4471 never bleeds into claim #4472
Codified knowledge	Skill files	Playbooks: coverage rules by state and form, documentation requirements per peril, fraud red flags
Tool access	Connectors to repos and CI	Policy admin, claims system of record, telematics, valuation data, payment rails, fraud databases
Maker and checker	One agent writes, another verifies	Extraction, coverage and fraud agents run separately, with a human adjuster as checker of record above threshold
State	A file outside the conversation	The claim file: every action and decision, timestamped and immutable

That last row carries more weight in insurance than in software. A messy state file costs a developer an afternoon. In claims it is what you hand a regulator or a plaintiff's attorney two years later, so design it as an audit log from day one.

Walking through a single claim

Take a windshield claim under a comprehensive auto policy. The loss is reported through the app or a transcribed call, and that event fires the loop. A workspace is created scoped to this claim only. One agent structures the report against the intake schema. A second checks the facts against the actual policy: coverage in force, deductible, glass endorsement, vehicle scheduled. A third scores fraud and severity independently, so it is not anchored by the coverage agent's read.

Then the gate. Low value, unambiguous coverage and a clean fraud score means the claim sits inside a pre-approved authority band, and the loop proceeds to a repair referral and payment with no human touch. Anything else routes to an adjuster, arriving with the extraction, the coverage read, the fraud score and the documents already attached. Either way the outcome is written back to the claim file with its reasoning.

Now run a total loss or a bodily injury claim through the same architecture. Same shape, far lower auto-approval ceiling, probably none at all. You are not building one flowchart per claim type. You are building one system whose gates you tune per line of business.

Where the human belongs, on purpose

"Human in the loop" is used loosely enough that it has stopped meaning much. In claims it can be defined precisely. A human is the checker whenever the cost of a wrong automated decision exceeds the cost of the delay caused by waiting for a person. That is a rule you can operationalise, not a sentiment. In practice it becomes explicit gates:

• Dollar thresholds tied to real authority limits, not round numbers.
• Coverage ambiguity, whenever confidence drops below a set bar or the policy language needs interpretation rather than lookup.
• Fraud signals above a defined score, regardless of claim size.
• Regulatory triggers, where a line or jurisdiction requires licensed sign-off however clean the claim looks.
• Claimant dispute, which routes to a person immediately, without exception.

The subtler decision is what the adjuster actually sees. If the loop dumps the raw file, nothing has been saved, because they still reconstruct the picture by hand. The loop's job is to hand over a reasoned claim: here is what was extracted, here is the coverage read and why, here is what drove the fraud score, here is what is still missing. The work shifts from assembling the picture to judging it, and that is a real change to the role.

What gets sharper as the loop gets better

A tighter loop does not remove risk. It concentrates it somewhere else.

Silent coverage misreads compound. An agent wrong two percent of the time, running on every claim, will eventually get a whole class of claims wrong the same way, and nobody notices until it surfaces as a market-conduct finding. The fix is sampling: route a random slice of auto-approved claims to a human even when the loop is confident.

Adjusters lose the reps that build judgement. If the loop absorbs every simple claim, junior adjusters stop seeing the easy cases that taught them the hard ones. Rotate people through auto-approved claims deliberately, even though the loop does not need them to.

Explainability is not optional. "The model was ninety-four percent confident" is not an answer for a regulator, and it is certainly not an answer for a claimant asking why their claim was denied. Every gate has to produce a reason a non-technical person can read.

A clean audit trail is not a correct decision. Logging is necessary but not sufficient. A beautifully logged wrong decision is still a wrong decision.

What this buys you

Done well, the loop does not eliminate adjusters. It changes what the first hour of a claim looks like. Simple claims move at the speed of the data rather than the speed of a queue. Complex claims land on a desk already assembled, with the reasoning attached and open to challenge. The audit trail becomes a by-product of how the system works rather than a report someone assembles later.

The architecture is close to what is being built for coding agents. The difference that matters is where the checker sits. In software the checker can usually be another model, because the cost of a bad merge is a revert. In claims it has to be a licensed human wherever the cost of being wrong is someone's coverage, a regulator's attention or a claimant's trust. Building that threshold in on purpose, rather than discovering it after an incident, is most of the actual engineering work.

Build the loop. But build it so the adjuster remains the one who is actually deciding.