Read Your Own Workflow, One Verb at a Time

Dearborn Labs·August 5, 2026·11 min read

A method any VP or CIO can run in one meeting, without a vendor in the room.

The short version (by humans, for busy humans)

We know how reading works now: most of this gets skimmed, or handed to an assistant to summarize. Fair.

This part was written by humans, for busy humans, in under 400 words. The full post below carries the depth: read it yourself, or let your AI ingest it. Either works.

The actual point: most carrier AI conversations start with the wrong question. "Where should we use AI?" gets answered at the level of departments and product categories, which is exactly the altitude where nothing operational ever happens. The useful question is smaller: what are the verbs?

Any piece of work is a chain of verbs. A new commercial submission breaks into five or six of them, not one task: read the broker's email, check eligibility, score the risk against loss history, summarize it for the underwriter, decide and sign. Each verb points at exactly one kind of capability: a rule, a model trained on your own data, a language model, or a person. Once you can name them, you can read any workflow in your shop yourself.

The renewal chain has more verbs than that tidy list, and the extra ones (refer, negotiate, document) are where the real argument lives. So are the two honest limits of the method: some of your "rules" only exist in a senior underwriter's head, and some work is simple enough that it ladders all the way to done with no judgment step at all.

The verbs that point at nothing are the point. Naming the steps that stay human is the half of the map a rented system can't touch, and it's usually the more valuable half to have found.

If you want the depth, it's below.


The full version (human on the loop, for depth, yours or your AI's)

Opening scenario

You run underwriting for a carrier somewhere between $200 million and a couple billion in premium. Two board cycles ago, somebody asked for the AI strategy update. What came back from the workshop was a list of roughly forty use cases, ranked by a firm that had never seen your appetite guide.

Half the list is something a spreadsheet macro already does. The other half assumes data your systems don't capture. You are no closer to an answer than before the workshop, and you already know the next board meeting is going to ask the same question again, in the same words, expecting a different result this time.

The list wasn't wrong, exactly. It was answered at the wrong altitude.

The problem

"Where should we use AI" sounds like a strategy question, but it behaves like a shopping question, sending you to a vendor list, a capability deck, or a use-case workshop. All three produce the same output: a ranked menu of things AI could theoretically touch, with no way to tell which ones are real and which ones have a person quietly doing the work behind the demo.

That's expensive, and not in the way the workshop invoice shows. The real cost is the eighteen months a carrier spends running pilots that never leave the sandbox, because nobody asked the smaller question first, the one about precisely what this piece of work requires someone or something to do.

Executives know something is off. That's why the question keeps getting asked again. Capability decks answer "what can AI do in general." They don't answer "what does this workflow, the one your team runs every day, actually need."

Here's what we learned

We've spent a decade running production AI inside a live carrier, and the method we use to open every engagement starts here: read the workflow, one verb at a time. It's the first hour of the work, not a slide.

1. Every piece of work is a chain of verbs, and each verb points at exactly one capability

Take a new commercial submission apart and it breaks into a chain, not one task: read the risk details out of the broker's messy email, check eligibility against your appetite, score the risk against your loss history, summarize it for the underwriter with the flags surfaced, decide and sign.

Read and summarize point to a language model, because turning messy text into structured facts is what language models are for. Check points to a rule, because whether this is a class and a state you even write is knowable in advance. Appetite is really two things wearing one name, though: hard screens are rules, and referral triggers are a designed handoff to a person, not a rule with extra steps.

Score points to a model trained on your own loss history. Decide and sign points to a person, because that's the licensed, accountable call. And whatever runs that whole sequence end to end, routing the edge cases to a human, is the agent.

A vendor will tell you this is workflow orchestration, and that they've been chaining steps like this for a decade. They're not wrong that the chain itself isn't new. Business process tooling has mapped sequences like this for years.

What's new is naming which links are rules, which are models, which are language, and which are a person. Orchestration diagrams never did that part, and it's the part that tells you where to spend and where to stop.

Tuesday morning: pick one workflow your team runs constantly and write its verbs down in order. You'll know within five minutes which ones you can already answer and which ones you're guessing about.

2. The renewal chain has more verbs than the tidy diagram, and the extra ones are the point

A submission is the clean version of this exercise. A renewal is the honest one, because it adds three verbs that don't fit neatly into "rule, model, language model, person."

Refer is the authority-grid escalation, and it's simultaneously the most rule-shaped step in the shop (the threshold that triggers it is usually written down) and the most human-adjacent (a person, not a formula, makes the call above it). Negotiate means terms are traded with the broker, not set unilaterally, which makes it a person's job by definition. Document is the file record somebody, eventually an examiner, reads later.

Re-pricing at renewal is mostly a rule, not a model: the filed rate order of calculation, with schedule credits and debits that are judgment operating inside filed bands. The machine learning lives in retention risk and loss propensity, not in the rate math itself. Getting this distinction right is the difference between a piece an underwriter nods along to and one they quietly correct in the comments.

Tuesday morning: if your renewal workflow diagram doesn't have a refer, a negotiate, and a document step on it, you've diagrammed the easy 70% of the job, not the renewal workflow.

3. Check only points to a rule if somebody already wrote the rule down

Here's the honesty beat that carries the rest of the argument. At most carriers, a real slice of underwriting appetite lives in the heads of two senior underwriters, not in a document a model could reference.

If the answer only exists in somebody's memory, no model can help you yet. The first job is writing the rule down.

That gap is the method's most valuable output, because it surfaces exactly where your "rules" are actually tribal knowledge, worth knowing whether or not you build anything on top of it.

Tuesday morning: the next time someone says "we have a rule for that," ask where the rule lives. If the honest answer is "ask Dave," you've found a verb that can't point anywhere yet, and that's a more useful finding than a new AI pilot.

4. Some work ladders all the way to done, and the trade from there runs left to right

The second honesty beat: not everything is a judgment call in disguise. A certificate of insurance request is a rule and a small language model, with no judgment step anywhere in it. That's a real win, and carriers should take it rather than hold out for a bigger project.

Beyond that, there's a trade to be honest about. Rules are predictable in advance, auditable off the page, and rigid. Agents are flexible, traceable after the fact through their logs, and harder to predict going in.

In between sit the models actuaries have filed for decades, interpretable because regulators require it. Moving right buys flexibility and costs certainty in advance. Choosing where to sit on that line, one decision at a time, is most of what AI strategy actually is. (That same trade is what a regulator's evaluation tool eventually asks you to defend, but that's a different post.)

Tuesday morning: for any AI decision on your roadmap, ask where it sits on that line, and whether that's where you meant to put it or just where the vendor's default landed it.

5. The verb map is the ownership stack, read from the bottom up

Line the verbs up and a pattern falls out. Read, summarize, and draft, the language-model verbs, sit in a swappable layer, since a competitor can buy the same software tomorrow. Predict points to your own loss history instead, which nobody else can buy at any price, and decide points to your judgment, the one part of the map that only you can supply.

That's the ownership question restated from the bottom of the workflow instead of the top of a slide: the parts of your map worth owning long-term are the parts a rented system can't contain, and the verb chain shows you exactly which steps those are.

This holds most cleanly for lines with real proprietary loss history behind them. A thin book, a new MGA program, a line you've written for two years, sits closer to the swappable layer even on the predict verbs, and that's worth admitting rather than smoothing over.

Tuesday morning: ask which layer of your map you're actually investing in this year. If every AI dollar is going to the swappable layer, that's not wrong, but it's worth knowing it's what you're doing.

So what

None of this requires a vendor demo or a use-case ranking to run. Take one workflow, write its verbs down, and match each one to a rule, a model built on your own data, a language model, or a person. You'll have found the AI in that workflow and, more usefully, the steps that stay human, in about the same time it takes to read this post.

The human steps are the half of the map that's actually yours, not a remainder waiting for a better model to absorb them, and naming them precisely is half the discipline. The next time "what's our AI strategy" comes up, you'll have an answer that came from your own workflow instead of somebody else's slide.


You just ran this exercise on one workflow. DL Discovery runs it across your operation over six weeks, with our operators sitting alongside your team rather than handing you a deck and leaving. If that's useful, reach out.

// Key Questions

What does it mean to "name the verbs" in an insurance workflow?

Naming the verbs means breaking a piece of work into the specific actions it requires, such as read, check, score, summarize, or decide, so each action can be matched to the right capability instead of labeling the whole workflow "an AI project." A commercial submission, for example, is five or six verbs chained together, not one task.

What's the difference between a rule and a machine learning model in underwriting?

A rule is a deterministic check where the answer is knowable in advance, like whether a risk falls inside an approved class and state. A model is trained on your own loss history to score things that don't reduce to a yes-or-no, like retention risk or claim severity, and its accuracy depends on how much of your own data it learned from.

Is chaining AI steps together the same thing as workflow orchestration?

No. Business process and workflow tools have chained steps together for years, so the chain itself isn't the news. What's different in the verb method is that each link in the chain gets named as a rule, a model, a language model, or a person, which tells you where the judgment sits and where a vendor's "orchestration" pitch is quietly routing around a step that should stay human.

Which steps in an insurance workflow should stay with a person rather than AI?

Any step that requires a licensed, accountable judgment call, such as deciding and signing a submission, negotiating terms with a broker, or referring a file up an authority grid, stays with a person. The verb method's real output is a precise list of these steps, not a leftover category for whatever the model couldn't handle.

How is naming verbs different from academic research on tasks and jobs?

Economists including Erik Brynjolfsson and Tom Mitchell have argued that AI reshapes jobs by affecting individual tasks within them rather than replacing whole occupations (MIT Sloan, "Machine Learning Will Redesign, Not Replace, Work"), and more recent work extends that into how tasks chain together (NBER Working Paper 34859, "Chaining Tasks," 2026). That research answers whether a task is economically suited to machine learning. The verb method answers a narrower, more immediate question: reading your own workflow well enough to get an executive to the first honest map of it in one meeting.

How does a carrier actually start applying this?

Pick one workflow the team runs constantly, write down every verb in order, and try to classify each one as a rule, a model, a language model, or a person before moving to the next. The verbs you can't classify without asking someone who's done the job for years are usually the most valuable finding in the exercise.

Share
← Back to Insights