A water damage claim comes in with two overlapping causes: a burst pipe and a roof leak from the same storm, filed six days apart by the same policyholder. A rules engine sees two claim IDs, two independent branches, and no field for "these might be the same event." It either processes them as unrelated — paying out twice against a single-occurrence deductible — or kicks both to a manual queue with no note explaining why, and an adjuster starts from zero. That's not a hypothetical. It's what happens every week wherever claims logic is built as a decision tree.
The rules engine doesn't fail loudly, it fails quietly
A rules engine is a set of if/then branches someone wrote in advance. It works exactly as well as the person who anticipated the case in front of it. When a claim doesn't match a branch, most systems don't raise a flag that says "I don't know what this is" — they force it down the nearest branch anyway, because that's what the code path does.
The result is claims that get auto-approved because they technically matched a keyword, or auto-denied because a required field was blank for a reason the form never anticipated. Either way, there's rarely a record of the judgment call, because no judgment was made. There's a log line showing which branch fired, not a reason. When a regulator or a policyholder's attorney asks why a claim was denied eighteen months ago, "the system matched rule 4.2.1" is not an answer anyone wants to give under oath.
The agent has to reason, but reasoning without a gate isn't safe either
An agent built on claims data can actually read the file — the policy language, the adjuster's prior notes, the loss history, the photos, the correspondence — and reason about whether this claim looks like the last one or looks new. That's the Knowledge principle: the agent is grounded in the insurer's own policy documents and claim history, not general knowledge about how insurance "usually" works. It's the difference between an agent that knows this carrier's actual exclusions and one that's guessing from training data.
But an agent that can reason about a claim can also talk itself into a bad decision with total confidence, which is arguably worse than a rules engine that fails obviously. So the agent doesn't get to just decide. It works through a policy-defined approval gate — Governance — that specifies exactly which claim characteristics require sign-off before payout: claims above a dollar threshold, claims with prior denials on the same policy, claims where the agent's own confidence in the coverage determination is below a set bar. Below the line, it moves the claim forward. At the line, it stops and routes to a named person with its reasoning attached, not just a ticket.
Underneath that, the agent doesn't operate as one login shared across every function. It has a scoped credential — Identity — that can read policy and claims data and draft a determination, and nothing more; it can't touch payment rails or change policy terms, because that was never part of its scope. And every step, from pulling the file to flagging the overlap to routing for approval, gets written to a record with the reason attached — Audit — so the answer to "why was this approved" exists before anyone asks. We build that record at the moment the action happens, not reconstructed after the fact from logs that were never meant to explain a decision. If a company wants to see what this actually looks like against their own claims workflow, that's what a diagnostic call is for.
Where this gets genuinely hard
Setting the approval threshold is a real judgment call, not a technical one. Set it too loose and every claim above a trivial dollar amount escalates to a human, which means you've automated nothing and added a review step on top of the old process. Set it too tight and the agent starts clearing claims a human would have caught — the exact failure the gate existed to prevent.
There's also a coordination cost to reasoning over a claim instead of just branching through it. An agent that checks coverage, cross-references prior claims, and screens for fraud indicators is doing three things that used to happen — or didn't happen — inside one opaque function call. More steps mean more places for the process to break, which is exactly why each step needs its own scoped access and its own record, rather than trusting the agent's overall output.
The question worth sitting with
If a claims examiner who approved a payout last year left the company tomorrow, could anyone else explain — with specifics, not a guess — why that claim was approved and not the nearly identical one that got denied? If the honest answer is "we'd have to reconstruct it from emails," that's the gap a rules engine was never going to close, and neither will an ungoverned agent.