Claims triage assistant grounded in policy documents

This is a pattern we would propose, not an engagement we have delivered. It is written out in full because the architecture is the part worth arguing about before anyone signs anything.

The problem this pattern addresses

Adjusters spend the opening of every claim reading policy documents to establish what is covered, then drafting a letter from a template nobody quite trusts. It is high volume, rules-heavy at the edges, and it absorbs a disproportionate amount of senior time before any judgement is applied.

How we would build it

A Copilot Studio agent grounded in the policy library, deployed inside Teams where the claims team already works. Retrieval runs over policy wordings and their endorsements. The agent extracts a coverage position, cites the specific clause it relied on, and drafts the opening letter for an adjuster to review and send.

• Retrieval scoped to the policy set in force on the date of loss, not the current wording
• Every coverage statement cites a clause, so the adjuster verifies rather than trusts
• The draft goes to a human queue — nothing sends automatically
• Refusal behaviour tuned so genuine ambiguity escalates instead of being guessed at

What we would hold it to

We would agree the acceptance numbers with you in discovery, before building. The measures that matter here are adjuster time to first letter, the proportion of drafts sent without material edit, and citation accuracy sampled by a human reviewer each week.

Where this gets hard

Policy wording versioning is the real difficulty, not the model. An insurer with years of endorsements needs retrieval that understands which wording applied when, and that is a data problem to solve before a prompt is written. The second difficulty is refusal: a triage agent that guesses on an ambiguous cover question is worse than no agent, so we would spend meaningful effort making it decline well.