The Shift

For two decades, the claims industry built systems to do one thing well: record. A claim happens, somebody opens a file, the file gets passed around, decisions are entered into fields, and at the end there is a clean, audit-ready record of what happened. The software got faster. The screens got prettier. The export to Excel got more reliable.

This was real progress. It is not what we are doing now.

A system designed to record what happened cannot, by changing its UI, become a system that decides what should happen next. The two architectures don't share a foundation.

What "digital efficiency" actually was

The first wave of insurance and claims software was a translation project. The fax became an email. The paper file became a PDF. The phone call became a portal. The clipboard became an iPad. Every step in the workflow got a digital wrapper, but the workflow itself — the sequence of human decisions, the order in which information had to be carried from desk to desk — stayed exactly the same.

This is why every operations team you've ever met has the same complaint: "the system" is faster than the old way, but the work isn't. There are still 12 steps. They are just 12 digital steps now.

The data model gives it away

If you open the schema of a legacy claims platform, you'll see it immediately. The central object is the file. Everything else — events, decisions, photos, documents, communications — hangs off the file as attributes. The file is the noun. People are verbs that act on it.

This is exactly the wrong shape for AI. An AI-native system has events at the centre. The file, if it exists at all, is a derived view — a snapshot you can render from the event log, not a thing you mutate.

What "AI intelligence" actually requires

The shift isn't "add an LLM to the existing system." It's a different foundation. Three properties that legacy claims platforms structurally cannot provide:

1. Events as first-class citizens

Every signal — a driver's photo, a body shop's status update, an insurer's approval — has to land as a discrete, time-stamped, structured event. Not as a row update on a file. The agent reasons over the event stream. The file is what you render at the end.

2. Decision boundaries that are explicit

Legacy systems blur the line between "data entry" and "decision making." A claims handler types into a field, and that field doesn't know whether the value came from a policy lookup, a phone call, a guess, or a calculation. An AI-native system has to mark every value with its provenance, because the agent's next decision depends on knowing which inputs are trustworthy.

3. Continuous execution, not request-response

A portal waits for someone to open it. An agent doesn't wait. It runs continuously over the event stream, and the moment a new signal arrives that changes the picture, it acts. This is a fundamentally different runtime model. You cannot bolt it onto a CRUD application.

---

Why this is a category shift, not a feature

The reason every "AI feature" we've seen launched on top of legacy claims platforms feels underwhelming is that the foundation is fighting them. The model gets handed a row from a database table and asked to be intelligent about it. It doesn't see the event stream. It doesn't have provenance on the values. It can't act continuously, because the runtime is request-response.

What you get is a chat box stapled to a file. Sometimes useful. Never transformative.

The leap is not from "no AI" to "some AI." It's from "system that records" to "system that operates." That's an architecture decision, made on day one, not a feature you add in version 4.2.

What this means in practice

For organizations evaluating where to invest, the practical question is no longer "which claims platform has the best AI features?" That question assumes a category that's about to be obsolete. The real questions:

• Does the system treat events or files as primary?
• Can the platform run end-to-end without a human in the request-response loop?
• When the agent makes a decision, can you trace it back to the exact events that supported it — for audit, for liability, for trust?
• Does the platform get measurably better with every claim it processes, or is each claim independent?

If the answer to those questions is structural — built into the foundation — you're looking at an AI-native operating layer. If the answer is "we're working on it" or "that's on the roadmap" — you're looking at a legacy platform with a new coat of paint.

The difference is invisible from the outside. It is the entire game from the inside.