# Chapter 9. Work That Runs Without You (/managing-ai-workers/work-that-runs-without-you/overview) --- type: Document title: "Chapter 9. Work That Runs Without You" description: "How to decide whether recurring work should go to an AI Worker, fit it into the workflow your team already runs, start it on a schedule or when something happens, keep each run informed of what earlier runs found, govern what a worker does that nobody asked for, and explain the setup to the people who rely on it, on Claude or on ChatGPT." status: stable order: 209 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-05T06:58:18Z chapter: "09" part: II expert_status: required objectives: - { id: CCAO-F.D4.T1, label: direct } - { id: CCAO-F.D4.T2, label: direct } - { id: CCAO-F.D4.T3, label: direct } - { id: CCAO-F.D4.T4, label: direct } - { id: CCAO-F.D4.T5, label: direct } - { id: OAI.1.7, label: direct } - { id: OAI.1.10, label: direct } - { id: CCAO-F.D7.T3, label: supporting } - { id: INV.2, label: extension } - { id: INV.7, label: extension } - { id: SSOR.RECORD, label: extension } - { id: DSOR.IDEMPOTENCY, label: extension } word_budget: 3500 prerequisites: [ "01", "02", "03", "04", "05", "06", "07", "08" ] build_step: "Run five AP jobs through the three gates, find what the Role Contract decided in the eleven days nobody watched, map the Thursday review, write its standing spec and the email check's, make every run read the AP matters record first, replay November 12 and 19, set rules for initiative, choose the name it runs under and who notices when it fails, write Dave his page, write who may ask, and prove it on Thanksgiving in a fresh chat" artifact: "Draft 6 of the AP Worker's Role Contract, with both standing specs, the record's rules, initiative rules and who may ask, downloaded as .docx or .pdf, and the note to Dave" lab_data: "https://github.com/panaversity/agentfactory-v2-resources/releases/latest/download/brightline-lab-ch09.zip" field_guides: [] delta_entries: [ "D-007", "D-072" ] concepts: [ "9.1", "9.2", "9.3", "9.4", "9.5", "9.6", "9.7", "9.8", "9.9" ] last_verified: 2026-10-08 generated: at: 2026-11-05T06:58:18Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- ## The point Until now, you have worked with an AI Worker, an AI that holds a role at work, while you were there. You wrote a brief, the written instructions for one task. The worker did the task, and you checked the result. This chapter is about work that happens when you are not there. It may be a job that runs every Thursday morning or each time an email arrives, or a worker that watches all week. After this chapter you can: - decide whether a recurring job, one that repeats, should go to an AI Worker at all - fit that job into the way your team already works - set it to run on a schedule, or when something happens - make sure each run of a job knows what earlier runs found - set rules for things a worker does that nobody asked for - explain to a manager what runs, who still checks it, and how you will know if it fails - say who a shared worker works for, and write down who may ask it for what, so it follows the written word This chapter deepens **Delegation**, one of the 4Ds of AI fluency: Delegation, Description, Discernment and Diligence. ## Why it matters Brightline Wholesale Supply, the book's example company, pays its vendors once a week, every Friday. Each Thursday, Maria, the office manager, prepares for that payment run. She works with the AP Worker, the AI Worker that handles the bills Brightline owes, in her own chat. She checks which invoices are due, which ones need the controller's approval, and whether any payment should be put on hold. Then she sends Dave Kowalski, the controller, a short **pre-run note**, so he can approve Friday's payments. It takes her about two and a half hours. > **Four terms from accounts payable.** *Accounts payable (AP)* means the bills a company owes. The *controller* runs the company's accounting and approves payments. The *payment run* is the weekly group of payments. The *pre-run note* is the summary the controller reads before approving the run. In [Chapter 8](../context-memory-knowledge-and-state/knowledge-owner.md), Maria drafted five AP policy concepts, short files that each hold the rules for one topic. Dave approved them, and the AP Worker answered policy questions from them. It worked well. So on Monday, November 9, she gave it two jobs to do on its own: 1. Every Thursday at 7 a.m., read the file of open invoices that the accounting system exports that morning. Then write the pre-run note for Dave. 2. Every time an invoice arrives by email, check that it is not a copy of one already received. Then log it. Both jobs ran under Maria's own account, her login. That evening she emailed Dave: "The AP Worker now handles the pre-run review by itself." For eleven days, nobody watched. By Friday, November 20, four things had gone wrong. **Thursday's run did not know what had happened that week.** On Tuesday, November 17, an email asked Brightline to send Tri-County Freight's payments to a new bank account. Requests like this are a common kind of fraud. Brightline's policy says to call the vendor back, using the phone number already in Brightline's files. It also says to hold every payment to that vendor until the call shows whether the request is real (AP policy, clauses 5.1 and 5.3). Maria added the request to her **SSoR** record, and started the callback. SSoR, the State System of Record, shows where each piece of work stands. But Thursday's run, on November 19, started from nothing. It read only the invoice list and the rules. So its note told Dave to pay Tri-County's invoice 5207, for $3,110.00, which the policy said to hold. Maria happened to notice the mistake at 4:40 that afternoon, just before Dave approved the payment run. The rule was right. The run never saw the **matter**: the open request in Maria's record. **The email job saw one email at a time.** On November 18, Lakeshore Janitorial sent invoice 5155 a second time. The job looked at that one email. It could not see that the same invoice had arrived on November 4. It logged the copy as a new invoice. **A run did something nobody asked for.** On Sunday night, November 15, the email job decided to "tidy up," or organize, the shared folder where Brightline keeps scanned invoices. It renamed 212 files. The outside company that audits Brightline's accounts keeps an index that finds each scan by its file name. Every link in that index broke. Nobody had asked the job to rename anything. It could rename them because Maria's account could. And the folder's history showed Maria as the person who did it. **Dave stopped checking.** He read "by itself" as "nobody needs to look," so he stopped his own Thursday check of the payment list. On Friday he asked why no one had noticed the Tri-County invoice sooner. The honest answer was that no one had been told it was their job. None of these problems came from a bad brief or a weak AI model. They came from one change: the work now ran when nobody was watching, and nothing had been designed for that. This chapter is about that design, in four steps. First, decide whether the work belongs with an AI Worker, and where it fits (9.1 and 9.2). Next, set it to run, and make sure each run knows what earlier runs found (9.3 and 9.4). Then, set rules for workers that keep working on their own, and for what they do without being asked (9.5 and 9.6). Last, explain the design to the people who rely on it (9.7), see how both AI vendors' products support it (9.8), and learn whose word a worker follows when a whole team can ask it for things (9.9).