Phase 14 · Lesson 46 of 54

Turn Every Agent Correction into a System Improvement

A correction that lives only in chat fixes one run. A correction promoted into a test, boundary, example, or tool improves every later run.

Lesson 46 of 54Learn + Build~65 minutesPython (stdlib)

Before this: Lessons 37 to 41 of Phase 14

On this page

Learning Objectives

  • Convert agent corrections into durable controls.
  • Place each control at the earliest layer that can prevent recurrence.
  • Deduplicate repeated lessons with stable fingerprints.
  • Retire controls that no longer protect a real risk.

Corrections Are Evidence

When you tell an agent “do not edit that file,” you have learned that the scope boundary was not executable. When you say “this output shape is wrong,” you have learned that an example or test was missing. When setup fails again, you have learned that environment knowledge belongs in automation.

Treat the correction as an observation about the work system, not as a prompt-writing failure.

Promote to the Earliest Effective Layer

Use this order:

Recurring failure Durable destination
Wrong result or regression Test or evaluation
Off-scope or unsafe action Scope or permission policy
Repeated setup or command mistake Automation or tool
Repeated output-format mistake Canonical example plus validator
Ambiguous local convention Instruction with a scenario check
Product disagreement Human decision record

Earlier controls are cheaper. A type that prevents an invalid state is stronger than a review comment that catches it later. A focused test is stronger than a paragraph asking the agent to remember.

Diagram (opens full size)

The Ratchet Record

Capture:

  • symptom;
  • root cause;
  • consequence;
  • recurrence count;
  • chosen control;
  • verification for the control;
  • owner;
  • date to review or retire it.

Do not promote every one-off preference. Promote a correction when recurrence or consequence justifies permanent complexity.

Separate Cause from Symptom

“The agent edited README” is a symptom. Possible causes include:

  • the task allowed the repository root;
  • docs were implicitly considered safe;
  • the plan bundled implementation and documentation;
  • two workers had overlapping ownership.

Each cause belongs to a different control. A rule that merely repeats the symptom will fail in the next slightly different case.

Controls Also Decay

Old controls can conflict, bloat context, and encode a system that no longer exists. Every promoted rule needs a retirement check. Remove or rewrite it when:

  • the underlying architecture changed;
  • a stronger executable control replaced it;
  • the failure has not recurred across a meaningful window;
  • the control creates more friction than the risk it prevents.

The goal is not the longest instruction file. It is the smallest system that preserves hard-won judgment.

Build It

The lab classifies corrections, promotes them into controls, fingerprints duplicates, and writes outputs/feedback-ratchet.json.

Run:

python3 code/main.py
python3 -m unittest discover code/tests -v

Add two differently worded corrections with the same cause. Improve the normalization until they collapse into one control without collapsing unrelated failures.

Exercises

  1. Take five corrections from a recent coding session and classify their real owners.
  2. Replace one prose rule with an executable test.
  3. Add consequence weighting so a severe first occurrence can be promoted immediately.
  4. Add an owner and retirement date to the lab output.
  5. Review one existing agent instruction and delete it only after proving a stronger control exists.

Further Reading

What You Keep

Keep outputs/feedback-ratchet.json. It is the durable end of the Agent-Assisted Engineering path and the input to future workbench changes.

Check yourself

Quick quiz

  1. What does a repeated agent correction reveal?

    1. A missing or weak control in the work system
    2. A reason to skip tests
    3. A need for more chat history
    4. Only a weak model
    Show the answer

    A. A missing or weak control in the work system Corrections are observations about missing tests, boundaries, examples, tools, or decisions.

  2. Where should a regression correction become durable?

    1. A longer prompt
    2. A test or evaluation
    3. A new model
    4. A meeting note
    Show the answer

    B. A test or evaluation Executable proof prevents the same wrong result from silently returning.

  3. Why find the root cause before writing a rule?

    1. It removes the need for evidence
    2. Rules require citations
    3. It avoids all complexity
    4. Symptoms can arise from different missing controls
    Show the answer

    D. Symptoms can arise from different missing controls A symptom-only rule fails when the same cause appears in a different form.

  4. When does a one-off correction justify a permanent control?

    1. Always
    2. Never
    3. When recurrence or consequence justifies lasting complexity
    4. Only after release
    Show the answer

    C. When recurrence or consequence justifies lasting complexity The ratchet should preserve meaningful judgment without accumulating every preference.

  5. Why fingerprint promoted controls?

    1. To hide ownership
    2. For visual design
    3. To replace verification
    4. To collapse repeated lessons without losing distinct causes
    Show the answer

    D. To collapse repeated lessons without losing distinct causes Stable identity prevents the same control from being added repeatedly.

  6. Why does every control need a retirement check?

    1. Controls can become stale, contradictory, or superseded
    2. Agents dislike instructions
    3. Tests cannot persist
    4. All rules expire daily
    Show the answer

    A. Controls can become stale, contradictory, or superseded The work system should remain minimal and current, not merely accumulate policy.

Questions people ask

How do you stop an AI agent from making the same mistake twice?

Promote the correction out of the chat. Add a test that catches it, a rule in the instructions, an example of the right result, or a change to the tool. Then confirm the fix works on later runs.

Should every AI correction become a new rule?

No. Recurring or costly mistakes deserve a durable fix, while one-off issues may not. Too many rules make instructions long and harder to follow, so keep only the ones that keep earning their place.

Next lessonDefine the Outcome Before You Choose the OutputPrevious: Delegate Agent Work with Isolation and Merge Contracts

Lessons from AI Engineering from Scratch by Rohit Ghumare and contributors, MIT license. Notes for owners by Lozo. License

Next step

Rather have it built for you?

Reading is optional. Tell me what's stuck and I'll build it into the business you already run.

  • A real conversation, not a pitch
  • You keep your accounts
  • Nothing sends without your yes