# 9.2 Fit AI into the workflow you already have (/managing-ai-workers/work-that-runs-without-you/fit-the-workflow) --- type: Document title: "9.2 Fit AI into the workflow you already have" description: "How to place a worker in the steps your team already follows: map each step, decide who owns it, avoid three common mapping errors, and measure before you switch." status: stable order: 209.2 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-10-08T06:12:34Z chapter: "09" part: II expert_status: required concepts: [ "9.2" ] last_verified: 2026-10-08 sources: - id: v1-workflow-design title: "Workflow Design & Diagnosis (Panaversity, first edition, verified 2026-10-08)" resource: https://agentfactory.panaversity.org/docs/workflow-design-diagnosis-crash-course generated: at: 2026-10-08T06:12:34Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:2f1e14f2a0f11dbc37eb5856ca9b7d35b4ce4894da74c3328cf61a3c17c03861 dirty: true ksor_version: 0.0.60 --- **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 step 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.[^v1-workflow-design] 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 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. 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. ![The title asks "Who does what in the Thursday review?" The line below it reads "Brightline's delegation map: the worker prepares, named people review and decide." A table has three columns: workflow step, who does it, and control or reason. Read the export and select invoices for the run: worker, from the current register and the payment-run rules. Apply payment and approval rules: worker, from the approved KSoR concepts. Flag duplicates and recommend holds: worker drafts, Maria checks, from the register and the SSoR matters record. Review and correct the pre-run note: Maria, by Thursday noon, a named human review before handoff. Resolve a bank-detail request: Maria, by verified callback, human only, policy 5.1. Approve Friday's payment run: Dave, using his own login, human only, for accountability. The last two rows show a lock. Below the table, two panels. "Three tests of ownership": reversibility, can it be undone? Stakes, what could an error cost? Accountability, who answers for it? "Three mapping errors": halo delegation, good at one step, given the next. Over-delegation, drafts a decision, then gets to make it. Unstaffed gate, a review exists, but nobody does it. A strip at the bottom reads "Baseline: 150 minutes each Thursday. Compare old and new over three parallel weeks: time, corrections, and errors."](img/delegation-map.png) *Figure 9.2. A delegation map for the Thursday pre-run review. The locks mark the two steps that stay with people.* [^v1-workflow-design]: Workflow Design & Diagnosis, Panaversity, first edition.