The Claim That Paid Twice

TL;DR: Claims automation decomposes beautifully into a pipeline of specialist agents, and that is exactly why it is the first place delegated authority goes wrong. Every hop resets the limit unless something enforces attenuation, and the failure is invisible in testing because each individual step behaves correctly.

Why claims goes first

Ask an insurer where they are putting agents and the answer is claims, almost every time. The reasons are good ones.

The work decomposes cleanly. First notification of loss, coverage check, liability assessment, quantum, fraud screen, payment. Each step has a specialist, a rulebook and a well-understood input. It maps onto a pipeline of agents so naturally that the architecture writes itself.

The volume justifies it. Claims handlers spend a large part of their week on files where nothing is in dispute, and every hour of that is an hour not spent on the file that needs judgement.

And the outcome is measurable in a way that most AI projects are not. Cycle time and leakage are numbers the business already tracks.

So the pipeline gets built. It works. It handles the straightforward files, and it hands the awkward ones to a person, and the metrics move.

Where it breaks, and why nobody sees it

Here is the configuration that ships.

The orchestrator holds authority to settle a claim up to £25,000. That number came from a real conversation with a real accountable person, and it is right.

It delegates to an adjuster. The adjuster is authorised to approve payments up to £25,000, because that is the size of claim it handles. Also right.

The adjuster delegates to a payments step, also £25,000, for the same reason. Right again.

Three correct limits. Now count what the pipeline can pay against a single claim on a busy afternoon, and the answer is not £25,000. Each delegation minted a fresh allowance, so the limits added instead of capping.

The reason this survives testing is that no test exercises it. Unit tests check each agent against its own limit and pass. Integration tests run a claim through the happy path, which spends far less than any of the ceilings. The failure only appears under volume, on a real book, and by then it looks like a reconciliation discrepancy rather than a control failure.

The question to ask a vendor

There is a version of this conversation that saves a lot of time. When an agent platform is being pitched into a claims programme, ask this:

If agent A delegates to agent B, and I revoke A’s authority, what is B allowed to do in the next thirty seconds?

The answers sort vendors quickly.

If the answer is “B has its own token with its own expiry”, the delegation is a copy, not a subdivision, and the limits will add.

If the answer is “we recommend short expiries”, that is a mitigation, not a control, and it will be tuned upward the first time it causes an operational problem.

The answer you want is that revoking A revokes B, and that the system can tell you what happened in the interval between the two, because there is always an interval.

Spend has to flow upward, not just downward

Attenuation on its own does not fix it. Suppose you tighten the pipeline so the adjuster gets £10,000 and the payments step gets £5,000. Better. Now run ten claims in parallel through the same orchestrator grant and you are back where you started, because ten children at £5,000 is £50,000 against a £25,000 root.

The property that actually bounds it is that consumption debits every ancestor. When a leaf spends, the debit lands on the leaf and on every grant above it. Then however the work is divided, the total against that claim is bounded by the number the accountable person signed for.

This has a consequence that looks wrong the first time an adjuster sees it. An agent with room in its own allowance gets refused, because an ancestor is exhausted. That is not a bug. The child’s allowance was never the operative limit, and the moment it appears to be, you have lost the ceiling.

It also needs its own outcome. “You are not permitted to do this” and “you were permitted but the tree has run out” send a claims supervisor to two completely different places, and a generic error costs them the diagnosis.

The fairness problem that sits next to it

While the pipeline is being designed, the other question arrives: can you show the fraud screen is not discriminating?

The honest answer has three parts, and insurers should be suspicious of any vendor who gives fewer.

A screen over declared attributes is not proof of fairness. It tells you the rates for the people who told you, which is a self-selected group.

A flagged cohort is not proof of discrimination either. It is grounds for a controlled analysis that somebody qualified performs, not a finding.

And nobody should be inferring a protected attribute in order to produce a chart. A decision carrying no declaration is reported as undisclosed. A cohort too small to measure is suppressed rather than given a rate the numbers cannot support. Both of those look like gaps in a dashboard and both are more honest than the alternative.

What to do before the pipeline goes live

Draw the tree and put a number on the root. Not on each agent. On the root, per claim, with a named person who is comfortable with it. If that person cannot be found, the pipeline is not ready, and no amount of engineering substitutes.

Run it recording, not refusing, for a fortnight. Against real volume. You are looking for the gap between what you think the pipeline can spend and what it actually attempts. The number is usually a surprise.

Rehearse the revocation. Pick a live claim, revoke the orchestrator, and see what the adjuster does next. Do it in a controlled window with somebody watching. Whatever happens is what will happen on the bad day.

Ask what the record says about the ones that were stopped. A pipeline that has never refused anything is either perfectly bounded or entirely unbounded, and your conduct regulator cannot tell those apart either.

The bottom line

Claims pipelines are the right first use of agents in insurance, and the architecture is sound. The problem is not the decomposition. It is that dividing the work quietly multiplies the permission, and every review of the individual limits passes while the total is wrong.

Put the ceiling on the tree, make spend debit upward, and the same pipeline becomes one you can put a number on and defend to a supervisor.