Lesson 9.29.2 Fit AI into the workflow you already have

In everyday life. A restaurant hires a new person to wash the dishes. The chef still tastes every plate before it leaves the kitchen.

What you will learn. How to place a worker in the steps your team already follows: who does each step, who answers for it, and how to measure the change before you keep it. You practice it in Task 2 of the lab.

Why it matters. A worker that fits the way your team already works is easier to check. And a step that nobody owns can stop being done, and nobody notices.

Recurring work is usually one step in a workflow your team already runs. A workflow is the series of steps a team follows to finish a piece of work. Fit the AI Worker into that workflow, rather than building a new one around it.

Start with a delegation map: each workflow step on one line, with who does it today and who should do it from now on.¹ For each step, ask three questions.

1. May it go to a worker? Is the data allowed into this tool, and can you give the worker every input the step needs?
2. Who should own it? Decide by reversibility (can the step be undone?), stakes (what does the worst error cost?) and accountability (is this a decision someone is responsible for?). If the step is a decision a person is responsible for, it stays with that person, even when the worker could draft it well.
3. What supports it? A standing instruction, an approved concept, a computed report, or a named person's review.

Three mapping errors are common. Halo delegation: the worker drafts one step well, so it is handed the next step too. Over-delegation: it drafts the approval memo, so it is allowed to approve. The unstaffed gate: a review exists in the plan, but nobody does it on the day. At Brightline, the book's example company, the unstaffed gate was Dave's Thursday check. Dave, the controller, stopped doing it.

Use an AI chat to do this analysis with you. After November 20, Maria, the office manager, asked the AI to interview her (5.4) about the Thursday review of invoices, one step at a time. Then she asked it to draft the map from her answers. One of its questions was what she checked before writing the pre-run note, the summary Dave reads before he approves the payment run. That question found the step she had left out: reading her SSoR record, the State System of Record, for open vendor requests. Next, she asked it to find gaps in her new spec, her written instructions for the job, and to test the spec against past weeks whose right answers she knew.

Research helps before you map. Maria wanted to know how other small finance teams check invoices for duplicates. A question that needs many sources suits research mode, which runs many searches and writes a report with its sources (0.2.2). One idea appeared in three independent sources, so she added it to the map as a check for Dave to approve. Another came only from a software seller's blog, so she left it out. Before she relied on the report, she checked its sources, as 6.5 shows.

Then measure. Before you switch, record a baseline, the numbers for how the step works today. Write down how long it takes, how many rounds of correction it needs, and how many errors reach the next person. Run the old way and the new way at the same time for two or three cycles of the work. Keep the new way only if it is better on the numbers you wrote down, not on how it feels.

On Brightline's map, the worker reads the morning's export of open invoices, applies the payment-run and approval rules, checks for duplicates and drafts the note. Maria reviews the note and corrects it. Dave approves the payment run using his own login. Two steps never move to the worker: verifying a bank-detail request, and approving the run.

Figure 9.2. A delegation map for the Thursday pre-run review. The locks mark the two steps that stay with people.