“None of that is underwriting. It is clerical work with an underwriter’s salary attached.”
I spent a morning last year sitting next to an underwriter who was working a US coast property submission. She had a statement of values running to a hundred and twenty locations, six years of loss runs as scanned PDFs, an ACORD form, and a legal pad. By lunchtime she had all of it into the rating system. She had not yet formed a single opinion about the risk.
That morning is why I am writing this.
The industry is in the middle of an AI stampede. Boards are asking for a generative AI story and they are getting one, usually something conversational bolted onto a core system that has not changed in twenty years. I understand the pressure everyone is under. But we are mistaking movement for progress, and nobody seems to be asking the obvious question out loud: why this technology, and why now?
The Problem Is Thirty Years Old
I want to answer that, and I will start by admitting the problem is not new. It is about thirty years old, and I have watched the industry run at it several times. In the nineties we rewrote the mainframes. In the 2000s we put the web in front of them. In the 2010s we built beautiful digital front doors, and then we spent a few years teaching software robots to click through screens on our behalf. Every one of those waves was sold as the end of rekeying. None of them ended it. The underwriter I sat with was still typing.
My explanation is that we kept working on the wrong layer. We made the form easier to fill in. We never gave the system any ability to make sense of what was on it. Generative AI is the first technology I have seen that can do the second thing, which is exactly why it feels like such a waste to spend it on chatbots.
Used properly, the two kinds of model work together. The predictive side knows what a risk tends to do. The generative side can read the messy documents that describe it. Put them in one auditable pipeline and you get something worth having. I have taken to calling it a system of reasoning.
The commercially interesting part is what you do not have to do. You do not have to replace the policy administration system. You do not have to migrate the data layer or go near the general ledger. They stay where they are. What changes is that the decisions running through them get reasoned instead of rekeyed. That is the work my practice at Artizent does, and most of our time goes into moving carriers and MGAs out of innovation sandboxes and into production, where the volumes are large and the money is real.
What Is Actually Eating the Morning
In Excess & Surplus, specialty property and workers’ compensation, unstructured data is the thing slowing everyone down. A submission arrives as a multi page ACORD form, several years of loss runs in PDF, and a statement of values with dozens of property locations in it. Somebody extracts the data by hand. Somebody normalizes the addresses, cross references the catastrophe hazard layers, and types the results into the policy admin system.
None of that is underwriting. It is clerical work with an underwriter’s salary attached. So when people ask me what automation should be doing in this part of the business, my answer is narrower than they expect. Get rid of the noise, so the underwriter can spend the morning on the risk rather than the paperwork. A chatbot does not do that.
Who Should Be Running the Room
I have seen enough of these programs fail to have a theory about why, and my theory is that the failure is organizational rather than technical. The engineers start first. The insurance people get pulled in around week six to review something. By then the model has been trained against an objective nobody in underwriting would have picked.
Coverage logic, binding authority, state filing rules, how you reserve. These are not details you collect later. They are design decisions, and they have to be made before anyone writes a prompt.
So we run it the other way round. Artizent is an AI engineering company. The engineering discipline is genuinely what we bring, thirty years of it, along with an exclusive partnership with Insurity. But the person leading the room is an insurance person. Engineers build the pipeline. Underwriters, actuaries and claims people decide what the pipeline is allowed to conclude. Working that way, we modernize core platforms into agentic workflows without replacing the system of record or the data underneath it.
What We Built
Astra is the platform we built for this. There are four layers, and all four are designed to sit on top of an estate rather than in place of one.
The Agents
Forty five self supervised agents and twelve prebuilt journeys, built for US and UK carriers, covering intake, E&S submission triage, rating and binding authority. These do the reading, the normalizing and the passing along that takes up the underwriter’s morning.
The Industry Intel Layer
Twenty four fine tuned models covering loss ratio, catastrophe modelling, workers’ compensation modifiers and fraud. Language models are good at documents. They are not good at risk. This is the half of the pair that is.
The Ontology Layer
Four P&C ontology packs with an MGA extension, premapped to Insurity ProSuite and RatioAI, holding structure across commercial lines, workers’ compensation and surplus lines.
I would draw attention to this one, because it answers the first question every CIO asks me, which is whether they will have to migrate. They will not. The ontology maps meaning onto the estate rather than moving the estate. It is what lets an agent work out that a field in a policy admin system written in 1994, a column in a spreadsheet and a clause in a manuscript endorsement are all talking about the same exposure, without anyone rewriting the system that holds it.
Astra for Engineering
The fourth layer gets talked about least and matters most, so I will spend a bit longer on it. Astra for Engineering is our AI development lifecycle platform. It is the thing we build, test, govern and release agents on.
Ordinary software lifecycles assume determinism. A test that passes today will pass next quarter, because the code has not changed. Agents do not work like that. Their behavior moves as the models move, as the data moves, and as the book itself moves. Run them through a lifecycle designed for a website and you end up with a pilot that demos beautifully and that nobody will let anywhere near production.
So in Astra for Engineering, quality assurance is a gate rather than a phase. Requirements are written against the ontology instead of a Word document, which means business intent can be checked by machine on day one. Agent behavior is regression tested against golden submission sets: real ACORDs, real loss runs, real statements of value, mess included. The evaluation harness runs before release and keeps running afterwards, so drift shows up as a number on a dashboard rather than as an email from an annoyed underwriter. And every release carries its guardrails, its evidence trail and its way back.
This is the difference between an AI demo and an AI system. It is also why I describe Artizent as an engineering company rather than a consultancy. Getting an impressive answer once is easy now. Getting the same answer ten thousand times, under audit, on a book that keeps changing, is engineering.
The Same Submission, End to End
Here is what that US coast submission looks like when the agents have it. The agent takes the payload and parses the 120 location statement of values, normalizing as it goes. It applies the hard limits it has been given, coastal tier aggregation among them, and stops straight through processing outright if the auto bind authority is exceeded. Instead of typing into a screen, it calls the rating APIs directly and returns base premium and state surplus lines tax in milliseconds. Where the standard forms do not cover the risk, the frontier model drafts the manuscript endorsement, a coastal windstorm provision say, and checks it against that state’s nonadmitted rules in about a second. Then it writes the bound policy header and the financials back to the core system.
It is worth noting what did not happen. Nothing was ripped out. The core system received the same record it would have received from the underwriter, and it has no idea anything is different. The estate did not change. It started reasoning.
The Accuracy Trap
Getting the pipeline running is the easy half. Keeping it safe in production is the other one, and in my experience the model itself is rarely the risk. The risk is how the numbers get read. A model that has been misread and then wired into a core system will cost you customers, attract a regulator, and leak indemnity quietly for a long time before anyone notices.
The trap is accuracy itself. It catches people three ways.
- Rare events. Raw accuracy tells you nothing when the thing you are looking for, a roof collapse or a complex fraud, almost never happens.
- The null model. Commercial fraud runs at about a tenth of a percent. A model that says “not fraud” to every policy is 99.9% accurate and catches nothing at all. I have watched that number get presented to a board with a straight face.
- Averages hiding failures. A pricing model at 90% overall might be at 98% on suburban new builds and 45% on urban legacy homes. The aggregate looks fine. The disparate impact question that follows does not.
Which Mistake Can You Afford
Data scientists reach for the F1 score to settle this. F1 is a mathematical convenience. It is not a business objective. You cannot maximize everything at once, so somebody has to decide which mistake the business can live with.
Recall is about what you catch, and its cost is what you miss. Where a miss is catastrophic, a bodily injury claim you did not flag that becomes a multi million dollar suit, you accept the lower precision and you staff the review queue for it.
Precision is about the cost of acting. Every false alarm burns Special Investigation Unit capacity, and past a certain point it kills the business case for touchless processing altogether.
Astra makes people price this out. What does a wasted adjuster review cost? What does a litigation blowup cost? Once those two numbers exist, the operating threshold picks itself, and it is the one that minimizes expected loss rather than the one that maximizes a score. This is not a data science decision. It belongs to an underwriter.
Six Questions Before Anything Goes Live
Before anything of ours reaches production it has to answer six questions. They are not sophisticated. Most of the failed pilots I have looked at would have been caught by one of them.
- Does the training data actually match this book of business?
- What makes the model fail? Commercial fleet policies, say. Name the cases.
- If a legitimate claim gets denied because of this, who pays for it?
- Is the API ready for real integration into the core platform, and what are the fallback rules?
- Claims inflation moves. Who owns the model when it degrades?
- What specific, observable number, at what level, sends this straight back to the manual queue?
The last one is the one people skip. A pilot without kill criteria is not a pilot. It is a commitment being processed.
One Last Thought
Insurers have been promised the end of manual work for thirty years and they have every right to be tired of hearing it. I am not going to argue that the technology is shinier this time, although it is. My argument is narrower. This is the first time we have been able to add reasoning to an estate instead of replacing it, and that only holds if the work is engineered properly and led by people who understand what an underwriter is deciding when they look at a risk.
The systems you already own are probably fine. They just do not think yet.
And the underwriter I sat with does not need a new policy administration system. She needs her morning back.