What agentic delivery changes in insurance

Most delivery constraints are about whether a change is correct. Insurance has one that is stranger and, in my experience, badly modelled in almost every engineering organisation that carries it: certain changes are not permitted to take effect until an external body has approved them, and correctness has nothing to do with it.

A rating change can be flawlessly implemented, fully tested, and shipping it can still be a regulatory problem, because the rate it produces has not been filed and approved in that jurisdiction. The code is right. The deployment is wrong.

This is a category of failure that no test suite has ever caught, because it is not a property of the software.

Why this matters more with agents

Under a conventional pace, the protection against this was social. Rating logic lived in a part of the system that few people touched, those people knew the filing rules, and a change to a factor triggered a conversation because the person making it knew it should.

That protection is made of institutional knowledge in individual heads, and it degrades in exactly the conditions agentic delivery creates: more changes, more contributors, less familiarity with any given path, and an implementer that has no concept of a regulatory filing at all.

An agent asked to refactor a pricing module will refactor the pricing module. If a factor moves in the process, it will not stop and ask whether that factor is on file. Nothing in its input suggests that question exists.

Make the filing boundary explicit in the codebase

The fix is not a policy document. It is to make the regulated surface visible to tooling, which means marking it in the place changes actually happen.

Whatever mechanism suits your stack: a directory convention, a path pattern, an annotation on the modules that produce filed values. What matters is that a machine can answer the question “did this change touch anything whose output is on file with a regulator” without a human recognising the module name.

Once that exists, several things become possible that were not. The change can be flagged automatically. Review can be routed to someone who knows the filing position. A criterion can be attached to that path requiring an explicit statement of the filing status. And the audit record can show, per change, whether the regulated surface was touched and who confirmed the position.

Criterion on any change under rating/filed/**:
State the filing position for every factor this change
alters, per jurisdiction, with the filing reference.
If no filed factor changes, state that explicitly.
“Not applicable” is an answer. Silence is not.

That distinction matters and I want to be direct about it. Nothing here determines whether a rate is properly filed. That is a judgement made by people who do that work. What the machinery does is guarantee the question is put, on every change, and that the answer is on the record. The failure mode being prevented is not a wrong answer, it is no answer.

The policy admin system is the other half

The second thing that defines this industry technically is that the core is old and the business logic is distributed across places that are not code.

A policy administration platform from the mid-2000s typically holds a substantial part of its behaviour in configuration: product definitions, rules tables, workflow settings, forms. That configuration is edited through an administrative interface, versioned poorly if at all, and it changes behaviour as decisively as any deployment.

This is a serious problem for everything in this series, and it deserves to be stated plainly rather than buried in the caveats. The entire premise of deriving ground truth from source control assumes the work lands in source control. Configuration edited through a vendor console does not. A team in that situation has a delivery record that is confidently incomplete, which is worse than obviously incomplete, because the reporting looks fine.

Where the throughput actually is

Given all that, the useful adoption path in insurance runs away from the core rather than at it.

Distribution and servicing surfaces: quote flows, portals, broker integrations, claims intake. Data and reporting pipelines, which are voluminous and well-specified. Integration code between the policy platform and everything around it, which is where a large share of engineering effort actually goes and which is ordinary software with ordinary verification.

Claims automation is the interesting middle case. It is high value and it is where the fairness and consistency questions live. A change to claims handling logic that is technically correct and produces a different outcome for a class of claimant is a problem that criteria will not catch, and it belongs in the same category as clinical safety in healthcare: a human review function that is now the constraint.

Where this breaks down

Marking the regulated surface requires knowing where it is, and often nobody does. In a system of that age, rating logic has usually leaked: a factor computed in a reporting query, a rounding rule in a document template, an adjustment in an integration adapter. The mapping exercise is the real work and it is measured in months, not sprints. Doing it is valuable regardless of any agent adoption.

Filing regimes vary by jurisdiction and this article flattens that. File-and-use, prior approval, and unregulated lines behave completely differently, and a carrier operating in many states or countries has a matrix rather than a rule. Any criterion has to be per jurisdiction, which makes it considerably heavier than the example above suggests.

Configuration-as-behaviour has no clean answer. I can describe the problem precisely and I cannot solve it with delivery tooling. If your platform does not export its configuration into something diffable, the honest move is to say the coverage gap exists, size it, and stop reporting metrics as though they covered everything.

Claims fairness is not a criteria problem. Consistency of outcome across groups is a statistical property of a population of decisions, not a property of a diff. Nothing in an acceptance-criteria pipeline evaluates it, and treating a green pipeline as evidence of fairness would be a serious error.

And actuarial correctness is out of scope entirely. Whether a factor is the right factor is not a software question. The machinery here ensures a change is authorised, recorded and reviewed by the right person; it has no view on whether the pricing is sound.

The takeaway

Insurance carries a constraint most industries do not: some changes cannot take effect until an external body says so, and no amount of testing detects a violation. The protection used to be that few people touched that code and they knew the rules, which is exactly the protection agentic delivery removes.

Make the filed surface explicit in the codebase so a machine can flag when it is touched, and attach a criterion that forces the filing position to be stated rather than assumed. Be honest about the coverage gap where behaviour lives in configuration rather than code. Point the throughput at distribution, servicing, integration and reporting, where the work is voluminous and verification is ordinary.

If you take one thing into next week: try to produce a list of every place in your estate that can change a filed value. If that list does not exist, that is the project, and it is worth doing whether or not an agent ever touches your codebase.