A claims professional has a policy in front of her. And a claim. Her job, for the next few hours, is to answer one question: does this policy cover this loss?

She opens the declarations page. Finds the form number. Searches for that form in the policy packet. Reads the insuring agreement. Flips to the exclusions. Finds an endorsement that modifies one of them. Checks whether the date of loss falls inside the policy period. Compares the claimant's location to the covered territory. Reads the notice requirements. Checks whether notice was given in time.

A few hours later, she writes a paragraph.

The paragraph is good. It's grounded in the actual policy language. It flags the one fact that's still missing. It tells the file handler what to do next.

This is coverage analysis. It's one of the most legally consequential things a claims professional does, and it has always been done manually.

We set out to change that.

The How-a-Human-Does-It Playbook

Mike Bruton, our CPO, had spent years doing this work before building software for it. Before writing a single line of product requirements, he wrote something else, the How-a-Human-Does-It Playbook. Not a PRD. Not a feature spec. A plain-English description of how a skilled claims professional approaches a coverage question.

It had three sections:

• Policy analysis: Read the whole policy, check it's complete, identify what questions need answering.

• Claim-specific analysis: Extract the facts, compare them to the policy, reach conclusions on trigger, exclusions, and conditions.

• Narrative: Combine the three conclusions into a written opinion.

We decided to build it. Or at least we decided to try. And started asking ourselves: how do you turn that playbook into a production system that can read hundreds or thousands of pages of policy language and produce a coverage opinion in a few minutes?

The Temptation We Resisted

The first instinct was the obvious one. You have a policy. You have a claim file. You have an LLM. Put them all in a prompt and ask for an opinion.

For simple cases, it works. A straightforward claim, no unusual endorsements-a single prompt can produce something reasonable. You can feel the demo landing.

But demos aren't production.

A commercial package policy with endorsements easily runs a few hundred pages. You can't fit that in a prompt. And more importantly, even when you can, you shouldn't. When an LLM reasons about policy language it hasn't actually read, it invents plausible-sounding exclusions. It confuses the standard form with the specific one that happens to be in front of it. It produces coverage opinions that sound authoritative and are subtly wrong.

In insurance, subtly wrong is dangerous. These opinions end up in claim files. They influence reserve decisions. They get quoted in coverage letters. They appear in litigation.

We needed something better than a confident guess.

The Shape of the Answer

The insight came from looking at that How-a-Human-Does-It Playbook again. Mike's process wasn't freeform reasoning. It was a structured legal argument. Each section had a specific question. Each question had a specific kind of evidence. The narrative at the end was a synthesis of three distinct conclusions, not one monolithic verdict.

That structure is what made an agentic architecture possible. We built a seven-stage pipeline. Fixed stages, deterministic order, no autonomous replanning. The LLM doesn't decide what to do next - the orchestrator does. What the LLM decides is what to look for.

In stages two, three, and four - trigger evaluation, exclusion evaluation, conditions evaluation - the model doesn't receive the policy text upfront. It receives facts and access to the Coverage Analysis Engine.

The Coverage Analysis Engine Is the Agent's Eyes

This is the part that took the longest to explain to people, and the most important thing to understand about how the system actually works.

The model isn't doing retrieval-augmented generation in the traditional sense-where you pre-fetch relevant chunks and stuff them into context before the prompt. The model is deciding what to retrieve. It's issuing targeted queries based on what it still needs to know. It's reading the results and deciding whether to search again.

Here's what that looks like in practice for exclusion evaluation:

1. The model receives pre-extracted facts: policy type, coverage form, date of loss, incident description.

2. It knows there's an endorsement that modifies the water damage exclusion but doesn't have the text. It queries the Coverage Analysis Engine.

3. The engine searches the documents and returns the relevant chunks. The exclusion has a carve-out for sudden and accidental discharge from a plumbing system.

4. The model needs to know if the loss qualifies. It queries again, asking about the specific cause of loss.

5. The claim file says "burst pipe." The model has what it needs. The exclusion doesn't apply.

That loop-hypothesis, search, read, refine-is exactly what the adjuster does when she flips between the policy and the claim file. The difference is that the Coverage Analysis Engine does it in minutes, and every query and result is logged.

Now the job becomes easier for the adjuster and less error prone. She has the facts of the case in front of her neatly summarized and organized. She can cross check the findings, make her edits and apply the final opinion. Hours became minutes! And more accurate!

When the Model Doesn't Know

Not every claim file has all the facts. Notice dates are missing. Location details are vague. Policy endorsements are referenced but not attached.

A single-prompt system handles this by guessing or hedging. Neither is acceptable. Our system has a third verdict: ”further information required”. When a stage hits a fact it genuinely can't resolve, the Coverage Analysis Engine flags the gap rather than guessing.

Those gaps surface as Unresolved Facts, each one named and explained. The adjuster knows exactly what's missing and why it matters.

What Stayed Deterministic

Stage five has no LLM call at all. After trigger, exclusion, and conditions evaluation return their conclusions, stage five combines them with pure logic.

• If any stage has unresolved facts -> ”further information required”

• If trigger not met -> ”may not be coverage”

• If any exclusion applies -> ”may not be coverage”

• If conditions not met -> ”may not be coverage”

• Otherwise -> ”likely coverage”

No model. No reasoning. No cost. Some things shouldn't be agentic. Knowing which things those are is most of the design work.

The Claim That Has Three Policies

Commercial insureds often carry multiple policies - a primary general liability policy, an umbrella, and an excess layer. The system runs each policy through the full evaluation pipeline independently. The claims professional sees a separate coverage opinion for each - not a single blended answer.

From Steps to System

Looking back at that How-a-Human-Does-It Playbook, almost everything important was already there. The three-section structure maps directly to the seven stages. The sequencing-check completeness before analyzing-is preserved exactly.

What the document didn't capture were the failure modes: what happens when a fact is missing, or when the model tries to let liability reasoning bleed into coverage conclusions. Those required engineering judgment and building guardrails.

But the mental model was there from the beginning. Coverage analysis is a structured legal argument. The conclusion follows from the evidence. The evidence has to come from the actual documents.

Two hours to a few minutes. The claims professional reviews the output, checks the flagged facts, and signs off. The work is hers. The reading was ours.