# 11.2 Ran is not the same as worked (/managing-ai-workers/when-the-worker-goes-wrong/ran-versus-worked) --- type: Document title: "11.2 Ran is not the same as worked" description: "Why a run that finished does not prove the work succeeded, and how to give every recurring job a success signal." status: stable order: 211.2 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-05T06:58:18Z chapter: "11" part: II expert_status: required concepts: [ "11.2" ] last_verified: 2026-10-08 sources: - id: v1-general-agents-web title: "General Agents on the Web: A Crash Course (Panaversity, first edition, verified 2026-10-08)" resource: https://agentfactory1.panaversity.org/docs/general-agents-web-crash-course - id: anthropic-opus-5-5 title: "Prompting Claude Opus 5.5 (Claude Docs, Anthropic, verified 2026-11-03)" resource: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5 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 --- **In everyday life.** The dishwasher beeps "done." The plates are still dirty, because the soap door never opened. The beep proved that the cycle ran, not that the dishes are clean. **What you will learn.** How to tell a run that worked from one that only finished, and how to make every recurring job say what it checked, every time. You practice it in Tasks 6, 7 and 9 of the lab. You also learn what to check before you restart a run that stopped partway. **Why it matters.** A job that speaks only when it finds a problem looks the same as a job that never ran. A well-organized result can also come from the wrong file. In this chapter's story, the AP Worker of Brightline Wholesale Supply, the book's example company, ran two recurring jobs on its own. It is an AI Worker that handles the bills the company owes. In one week in January 2027, neither job failed loudly, with an error that reached anyone. On Tuesday, January 12, the duplicate check, which runs on each invoice email, checked none of the nine that arrived. It posts a message only when it finds a duplicate, so it produced nothing, but nothing was also what success looked like. On Thursday, January 14, the pre-run note, the summary the controller reads before he approves each Friday's payment run, said "No invoices due this week." It was a well-organized note, but the job had read the closed 2026 register. In fact, 31 invoices were due. **Run evidence** shows that the mechanism ran: the job started, finished and produced an output. **Outcome evidence** shows that the work succeeded. That is, the right input was read, the result meets its Review Contract ([Chapter 6](../the-review-contract/agree-the-checks.md)), and it reached the right place. A Review Contract lists the checks you agree before the work. A scheduler shows run evidence.[^v1-general-agents-web] Only you, as the job's owner, can define outcome evidence. A run can also end on an update that says what it will do next, without doing it. That is run evidence too: a report, not proof that the work is done.[^anthropic-opus-5-5] A **success signal** is a visible sign that a run did its job.[^v1-general-agents-web] Give every recurring job a success signal. Three rules make a good signal: - **Say something every time.** "Checked 9 invoices, 1 possible duplicate" is a result. Silence means success only when a check outside the job shows it ran (Chapter 9). A job that never starts cannot report on itself. So for an event-triggered job, a line like that cannot come from the job itself. It comes from a separate scheduled check, like Chapter 9's deadline check. The separate check compares the invoice emails received with the emails checked, by message ID, the unique code each email carries. Counts are not enough: if one email was checked twice and another was missed, the counts still match. - **State the input first.** The Thursday note should have begun "Register: AP Register 2027, last entry January 13, 31 open invoices due." Then a wrong file would show on the first line. - **Fail loudly when the input looks wrong.** If the input is missing, out of date or far smaller than usual, stop and say so. When an expected output is missing, do not change the brief, the job's written instructions, yet. The brief may not be the cause. First check for a pending approval or question, a pause, a usage limit, a broken connector or a different destination.[^v1-general-agents-web] ![The title reads "Ran is not the same as worked." The line below it reads "A completed run does not prove a correct result." A panel on the left, "Run evidence," asks "Did the mechanism run?" Its three rows each have a check mark: Started, Finished and Output produced. Its last line reads "The run status shows execution." A panel on the right, "Outcome evidence," asks "Did the work succeed?" Its three rows each have a check mark: Right input read, Meets the review contract and Reached the right destination. Its last line reads "The owner defines what must be verified." Between the panels, a not-equal sign carries the words "Verify separately." Below, under "Brightline: the Thursday note," a panel marked with a cross reads "Tidy output, wrong source" and quotes "No invoices due this week." Its note reads "The job read the closed 2026 register." A second panel, "A checkable success signal," lists the source, AP Register 2027, and the last entry, Jan 13, 2027. It also lists the due-by date, Jan 22, 2027, and 31 open invoices, USD 86,240.15. Its note reads "Check these details against the source." A banner reads "State the input. Verify the result. Confirm delivery." The last line reads "Silence can mean no run. Use an independent check for missing runs."](img/ran-vs-worked.png) *Figure 11.2. A job that only reports problems cannot tell you it never ran.* **A run that stopped partway.** Some runs do not fail. They stop. Where the work runs decides how. Work on your own computer may stop when the computer goes to sleep or the app closes. Work in the cloud keeps going when you close the laptop ([1.5](../../ai-worker-paradigm/from-chatbots-to-ai-workers/both-ai-vendors.md)). But it cannot reach files on your computer while the app is closed, and it can stop at a usage limit. A run that stopped partway may already have done some of its actions. A finished-looking reply proves nothing either way, and neither does the worker's account of where it stopped. So before you restart it, find out what already happened. Read the run's record. Then look where the work lands, and list what is there. Restart from the inputs and that list, not from the conversation. A restart is safe for an action that gives the same result when done twice, such as rewriting a report file. An action that adds something, such as a row in a queue, a message or a payment, adds it again. A retry that flags the same invoice twice is a new failure, not a recovery. This is the same risk as a trigger that fires twice ([9.3](../work-that-runs-without-you/scheduled-and-event-triggered.md)). The same check answers it: before a run adds anything, it checks whether that thing is already there. So after a run stops partway, check what landed before you restart, and tell the worker to skip anything already on your list. [^v1-general-agents-web]: General Agents on the Web: A Crash Course, Panaversity, first edition. [^anthropic-opus-5-5]: Prompting Claude Opus 5.5, Claude Docs, Anthropic.