When a representation letter lands on a workers' comp claim, an experienced adjuster does roughly the same things every time. They acknowledge the letter, reach out to the claimant's attorney, adjust reserves now that an attorney is involved, and update the claim summary. Ask 10 adjusters for the sequence and you'll get the same list in slightly different orders, with a step or two of local flavor.
The same holds when a return-to-work note comes in, full duty or with restrictions, or a demand package. It even holds for silence: a claimant who hasn't heard from anyone in three weeks is its own trigger, with its own response. These sequences repeat from file to file, and mostly from shop to shop. An adjuster with 15 years of experience has run some of them a thousand times, and could run them half asleep.
Workflow orchestration gets defined in a lot of ways. If we keep it really simple, it comes down to this: when something needs to happen on a claim, the right response follows.
Done well, the routine response happens on its own, and the exceptions land with a person quickly. The way to get there is a system that learns the actions taken on past claims, when they were taken and what they led to, and then executes them automatically. In other words, it's like a new hire on the claims floor, one who happens to have read every claim the company ever closed and can be trusted with the motions everyone already agrees on. The calls that matter stay with whoever owns the file. And like any new hire, the system gets brought along in phases. None of this was practical before, because most of a claim file is prose. But language models can finally read it.
Where to Start
The place to start is simple, getting the work itself into view. What's happening on each file and what the adjuster is doing about it, gathered in one place instead of spread across the diary, the inboxes, and the core system. Today the diary is the closest thing to that picture. A file comes up because 60 days passed, not because anything happened on it, and the first half hour goes to finding out whether anything did.
An overview like that is worth building before a single routine runs on its own. It shows what changed overnight and what's waiting on a decision, and it starts the adjuster's morning at the right files. It also means the state of a file no longer lives only in the adjuster's head, so nothing stalls when someone is out for two weeks, and a handoff doesn't start from zero. And it gives a claims operation something it has never really had: a clear picture of its own work. Everything else, the suggestions and eventually the actions, builds on that clarity, because work can only be handed to a system once it can be seen. The phases are how that picture gets built.
Phase One: Analyze
Every one of these sequences starts from a trigger. Sometimes the trigger is an event, like a letter arriving or a claimant going quiet. Sometimes it's a scheduled action: a state deadline on the first payment, or a follow-up that was promised and hasn't happened yet. The first phase is about proving those triggers get caught. The system doesn't act on anything yet. It reads everything that arrives and reports what it sees: what changed on the file since yesterday, and which of those changes should set a sequence in motion.
The same reading, pointed backward, is where the insights start. Once the files are readable, questions that used to require a file review project can be answered directly from the data: how much subrogation actually went by unnoticed last year, or how long attorney letters sat before anyone opened them. Each of those numbers is a count of missed triggers, and together they make the case for orchestration from the operation's own files.
A system that only watches already earns its keep. Nothing important sits unread anymore, and leadership questions stop being answered by sampling and gut feel. It's also the phase today's models are ready for. Reading a claim file and noticing what matters is exactly the kind of work language models have become reliably good at, and the cost of a miss is an alert that didn't fire, which is no worse than the status quo. Every week of watching also builds a record of what the system noticed and what the adjuster then did about it. That record is what justifies the next phase.
Phase Two: Suggest
In the second phase, the system starts making recommendations. The acknowledgment letter shows up drafted. The claim summary is updated and waiting. The reserve review appears as a proposed task with the reasoning attached, and the wage statement request is ready the day a claim turns lost time. So is the status update to the injured worker, who mostly just wants to know that someone is paying attention. Plenty gets corrected before it goes out, and some suggestions get ignored, which is useful information in itself.
Reviewing this output is real work. If the system surfaces 40 suggestions a day to an adjuster who already has 30 diary entries due, nothing has been automated; a backlog has been created with extra steps. The review process has to be staffed and sized like any other part of the operation, and it has to be worth the adjuster's time. The corrections matter most. Every fix an adjuster makes to a suggestion is a lesson, and a system that keeps those lessons gets better every week it runs, while a system that throws them away will be making the same mistakes a year from now. The way out of this phase is consistency, motion by motion: suggestions going through untouched often enough that the approval becomes a formality.
Phase Three: Act Where Possible
The last phase is the one vendor demos lead with, and the one that should come last. Some motions start running on their own, but only the ones with a record behind them, and that record is task by task. Sending an acknowledgment letter unsupervised is a very different proposition from touching a reserve unsupervised, and phase two produces the evidence for that call: how often adjusters approved each kind of suggestion unchanged, and where the overrides cluster. Settlement authority for a new adjuster grows in the same way, with the track record. Autonomy should expand at the pace the record justifies.
The AI models will keep getting better. That doesn't change the design. It just changes how quickly a claims operation moves through the phases.
