An AI Mission for Claims Processing

Every claims organisation has a number it is proud of and a queue it does not talk about. The number is the straight-through rate. The queue is everything that number left behind — and that is where almost all the remaining cost lives.

A water damage claim arrives on a Tuesday morning and clears the first three gates without a human touching it: the policy is in force, the peril is one the system recognises, the date of loss falls inside the term. Then it stops. The field adjuster's narrative describes the damage in a way that does not map cleanly onto any category the intake model knows, one of the vendor invoices has come in as a photograph of a paper receipt with a handwritten line item scrawled at the bottom, and the sequence of events the claimant described over the phone does not quite line up with the timestamps on the mitigation contractor's estimate. Nothing here is fraudulent. Nothing is even unusual by the standards of a person who has worked claims for a decade. The claim is simply not shaped like the claims the pipeline was built to move, so it falls out, and at the instant it falls out it stops being a data problem and becomes a person problem: it lands in a work queue where an adjuster will eventually pick it up, read the entire file from the beginning, work out what is missing, go and get it, and decide.

For years the industry's improvement programme has been aimed almost entirely at making that fall-out rarer. Every point of straight-through rate has been fought for with better intake forms, tighter rules, more integrations, cleaner data at first notice of loss, and each point has been genuinely worth having. But anyone running that programme now knows the shape of the curve they are on. The early gains came easily because the early gains were the claims that repeat — the simple, high-frequency, well-documented losses that look like each other. What is left in the exception queue is not a random sample of claims that happened to fail. It is the residue of a selection process that has already removed everything resembling anything else, and it resists the next rule for exactly the reason it resisted the last one.

The straight-through rate has been optimised against itself

Rules-based automation works on regularity, and it works beautifully on it. Each rule encodes a pattern that someone recognised in advance and expects to see again, which means the value of the rule is a function of how often the pattern recurs. Run that logic forward across a decade of continuous improvement and the outcome is arithmetically inevitable: the patterns worth encoding get encoded first, the marginal rule covers a thinner and thinner slice of volume, and the ruleset as a whole grows more brittle because each new branch interacts with every branch already there. Claims leaders feel this as a project that used to deliver two points a year and now delivers a fraction of one, at rising cost, with more regression testing each time. The straight-through rate has been optimised until it began to work against itself.

Meanwhile the cost profile has quietly inverted. The claims that go straight through consume almost nothing — that was the point of the exercise — so nearly the entire operating cost of the function, and nearly all of its cycle time, now sits inside the minority of claims that did not. Those are the files that get picked up, put down, re-read by a second person after a handoff, sent back to the claimant for a document that was requested badly the first time, reopened after a supplement arrives, and escalated when someone loses patience. Anyone who has watched an exception queue closely knows that the elapsed time on those claims has very little to do with the difficulty of the underlying decision and a great deal to do with the waiting: waiting to be picked up, waiting for information, waiting for whoever knows this policy form to come back from leave. It is also, uncomfortably, where the customer's opinion of the insurer is formed. No policyholder builds a lasting view of a company from the claim that paid in a day without human contact. They build it from the one that fell out.

An exception is a reasoning problem wearing a rules problem's clothes

Watch what an experienced adjuster actually does when they open one of those files, and it becomes obvious why another rule was never going to help. They do not apply a procedure so much as reconstruct a situation. They read the loss notice, the field narrative, the photographs, the repair estimate, the policy form together with whichever endorsements attach to it, the claimant's prior history, and the vendor's invoice; they hold those sources side by side; they notice that two of them disagree about something material; they form a view about which is more likely to be right and why; they identify the one document that would settle it; and then they go and ask for that document specifically, in language a stressed human being can act on. That is an act of reading and inference across unstructured, partially contradictory material, and the reason it never automated is not that the stakes are high — plenty of high-stakes work has been automated. It is that the work cannot be decomposed into steps ahead of time, because the very definition of a fall-out is a claim that did not match the steps anyone drew.

This is the part of the picture that has genuinely changed. Software that can read a narrative, reconcile it against a schedule, notice that an invoice line has no corresponding item in the estimate, and articulate that discrepancy in plain language is a different kind of capability from a rule engine, not a faster version of one. It is also, unfortunately, the thing most likely to be sold to a claims organisation in a form that does not actually do it. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, naming escalating costs, unclear value, and what it calls "agent washing" — older tools relabelled without the underlying change in what they can do unattended. A rule engine with a chat window on the front still hands the exception back to the queue. It has changed how the work is requested and nothing at all about who does it.

Autonomy in claims means preparing the decision, not making it

None of this is an argument that software should approve, deny, or adjudicate a claim. It should not, and the reason is not merely regulatory. A coverage decision is a determination about a person's home, health, livelihood, or business, made under a contract that person is entitled to have interpreted by someone who can be asked to account for the interpretation. That accountability cannot be delegated to a system, and an operating model that quietly tries to is building a liability rather than an efficiency. The line that matters is between the decision and everything that surrounds it, and virtually all of the exception queue's cost sits on the surrounding side of that line.

What can be absorbed is the reconstruction: retrieving every document attached to the claim and every relevant clause of the governing policy, reading them against each other, extracting the facts from unstructured narratives and photographed invoices, surfacing the specific contradiction rather than a generic flag, drafting the precise information request that closes the gap, chasing it when it does not come back, and assembling all of it into a file an adjuster can decide on in minutes instead of an hour. This is what a claims mission looks like when it is designed honestly — specialist agents working intake, document extraction, policy interpretation support, discrepancy detection, and claimant correspondence, coordinated by a reasoning layer that can handle a file it has never seen before, with the observations behind every conclusion visible and a human-in-the-loop gate on anything that touches coverage or payment. It is the same premise behind the wider shift toward autonomous enterprise operations, and the thesis behind platforms like StudioX's claims missions, where the operating principle is that the organisation owns the decisions and the agents own the preparation. The adjuster is not removed from the file. They are removed from the two hours of assembly that stood between them and the ten minutes of judgement they were hired for.

The mental model worth carrying out of this is that fall-out is not a failure. A claim that leaves the automated path has been correctly identified by the pipeline as a claim that requires thought, and a system that never fell anything out would be a system quietly deciding things it should not decide. The mistake was treating the fall-out rate as the metric and the exception queue as the place where good process goes to die. Measure instead what happens to a claim in the hour after it falls out — how much of the reconstruction happens without a person, how complete the file is when a human first opens it, how specific the first request to the claimant is. Insurers have spent a decade making sure fewer claims need thinking about. The next decade belongs to the ones who make thinking fast.