A claim arrives as a mix: a form, an email, photos, an estimate, and sometimes a police or incident report. Before an adjuster can decide anything, someone has to read it, find the policy, and work out which parts of the policy apply. Much of that is reading and cross-referencing, and the policy language is long, with endorsements that modify the base form.
This is a document-heavy task with a fixed order of steps, so it is a workflow, not an agent. The model reads and maps. Code calculates. The adjuster decides.
The design
- Claim fileforms, email, PDFs, photos
- Extractsmall model, fixed schema
- Validatecode: fields, dates, policy match
- Map to policyloss facts to clauses, cited
- Computecode: deductible, limits, period
- Briefsummary and open questions
- Adjusterdecides coverage
- Claim recordbrief, citations, edits
- Extract. A fast, inexpensive model fills a fixed schema: claimant, policy number, date and place of loss, loss type, amounts claimed. Structured outputs constrain the response to the schema, so downstream code gets valid data. Anthropic notes that numeric range constraints are not enforced in the schema, so check those in code.
- Validate. Code confirms the policy exists, was in force on the date of loss, and matches the insured. A failure here ends the chain and routes to a person. No model judgment is needed to find that a policy had lapsed.
- Map to policy. The base form and its endorsements are placed in the context in full. The 1M-token window makes this practical for long policies. The model identifies the clauses that bear on the loss and states, for each, whether the facts appear to fit. The Citations feature returns the exact passages behind each statement so the adjuster can click through.
- Compute. Code applies the deductible, sub-limits, and waiting periods from structured policy data. The model never does this arithmetic.
- Brief. The model writes a short summary with open questions: missing documents, ambiguous facts, clauses where a reasonable reader could disagree.
The principle behind the split
The model is strong at reading unstructured text against other text. It is the wrong tool for a date comparison or a limit calculation, where a deterministic answer exists and an error is costly. Assigning each step to the right kind of component is most of what makes the system defensible. It also lets you test the code steps with ordinary unit tests and save the evaluation effort for the reading steps.
Where the human matters
Coverage decisions affect people, and a denial can be challenged. The adjuster owns the decision, and the interface should show the brief and the cited policy text side by side, so a review takes a short time and the reasoning is visible. Add routing on top. If the mapping step reports low confidence, finds conflicting endorsements, or sees a high claimed amount, the file goes to a senior adjuster with the flagged reasons. Fraud assessment is a separate system with its own governance. Do not let this one infer it.
How to evaluate it
- Replay closed claims. Use a stratified set across loss types, with the adjuster's recorded coverage decision as the label.
- Grade clause identification. Did the brief surface the clauses the adjuster relied on? Code can check this against the clause IDs in the adjuster's notes.
- Grade citation support. Does each cited passage support the statement? Use a model judge from a different model, with a person sampling.
- Track the hard cases. Separate results for claims with endorsements, multiple coverages, and ambiguous wording. That is where errors concentrate.
Adjacent opportunities
Anthropic's financial services material also describes reviewing actuarial workbooks and regulatory filings, checking formulas, flagging anomalies, and drafting filing narratives, with a human keeping sign-off on reserves. The same split applies: the model reads and drafts, code and people own the numbers and the decision.
This is a reference design. It describes how we would build the system and cites Anthropic's documentation for platform facts. It is not a client case study, and the figures it uses are list prices or worked examples, not results.
Have a process like this?
Bring it to a 45-minute working session.