# 11.6 Make the fix stick, and optimize from feedback (/managing-ai-workers/when-the-worker-goes-wrong/make-the-fix-stick)

---
type: Document
title: "11.6 Make the fix stick, and optimize from feedback"
description: "How to move a fix out of a chat so it lasts for everyone, and use feedback and a baseline to improve the work."
status: stable
order: 211.6
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-10-08T13:21:13Z
chapter: "11"
part: II
expert_status: required
concepts: [ "11.6" ]
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-08T13:21:13Z
  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.** You remind a new roommate every week to lock the back door. A note on the door works when you are away. Your reminder does not.

**What you will learn.** How to give a repeated correction a lasting home in the worker's setup, and how to measure whether a change made the work better. You practice it in steps 7 and 8 of the lab.

**Why it matters.** A correction made by hand every week costs time every week, and it is lost when that person is away.

In this chapter's story, Brightline Wholesale Supply, the book's example company, uses an AP Worker, the AI Worker that handles the bills the company owes. Maria, the office manager, runs it day to day, and Dave Kowalski, the controller, approves its work. Jordan Ellis, a clerk, uses it too.

A fix that stays in one chat will be needed again by someone else. **Promotion** means moving a fix out of a chat and into the configuration, the worker's setup, so it lasts for everyone.[^v1-workflow-design] Ask one question: is the fix a rule, a reference, a procedure or a boundary?

| The fix is a | It goes to | Example at Brightline |
| --- | --- | --- |
| *Rule*, a limit that always applies | Standing instructions, rules that load with every conversation | "Never state vendor terms that are not in the vendor record." |
| *Reference*, material the worker must read | The KSoR, the Knowledge System of Record, through its owner | The small-supplier promise, as a concept Dave approves (Chapter 10) |
| *Procedure*, steps done in order | A skill, a saved procedure the worker follows | The Thursday note's checks and layout |
| *Boundary*, what the worker may reach or do | The Authority Envelope, the written limit on what the worker may do (Chapter 7) | Read-only access to the Remittances folder, and no more |

A fix in the wrong home fails without any warning. For example, a procedure written as one instruction loses its steps.

**Feedback is data.** Maria keeps a log of her corrections to the Thursday pre-run note, the summary the controller reads before each Friday's payment run. Over six weeks, the log showed the same three corrections every time. Credit memos, which lower what Brightline owes, were listed as amounts owed. The note gave no warning about small suppliers whose invoices were close to 15 days old. Brightline promises to pay them within 15 days (Chapter 10). And amounts were shown without cents.

Three signs point to work worth fixing. *Repetition* means you give the worker the same thing every run. *Correction* means you fix the same flaw every time. *Variance* means different people get different results.[^v1-workflow-design] Maria's reply to a vendor's dispute, written by Maria herself, and the worker's draft from Jordan's brief looked nothing alike. No single person sees variance in their own work. The reviewer, who checks everyone's work, does.

Before changing anything, take a **baseline** (Chapter 9). A baseline is one unchanged run, with its time, revision rounds and manual steps.[^v1-workflow-design] Maria's baseline was the note of January 7, with 40 minutes of corrections. Then optimize, or improve, the work in this order. First **consolidate**: merge steps that need the same background. Then promote what remains. Choose the metric, the thing you measure, that matches the work. For a payments note, accuracy comes before speed. Then run the old and new setups at the same time for two or three cycles, such as two or three Thursdays, before you switch.

![The title reads "Turn corrections into lasting improvements." The line below it reads "Record the pattern. Save the fix. Measure the result." Six numbered steps run in a loop. Step 1, "Log feedback": "Record the error, correction and evidence." Step 2, "Find the pattern": "Look for repeated corrections and inconsistent results." Step 3, "Give the fix a home": Rule, Reference, Procedure, Boundary. Step 4, "Capture the baseline": "Record current performance before applying the change." Step 5, "Compare side by side": "Test current and revised setups on the same cases." Step 6, "Adopt if verified": "Approve the better setup. Keep monitoring." An arrow leads from step 6 back to step 1. In the middle, a panel reads "Consolidate before you promote" and "Merge repeated fixes. Resolve conflicting instructions." A banner at the bottom reads "A correction becomes configuration only after review and testing."](img/feedback-loop.png)

*Figure 11.5. Corrections become configuration, and configuration is measured.*

[^v1-workflow-design]: Workflow Design & Diagnosis, Panaversity, first edition.