Build A Repeat-Mistake Counter
Notes about mistakes are useless without a count. Here is the ledger, the escalation ladder and the one habit that makes it work.
Notes about an agent's mistakes are nearly useless without a count, because the fifth repeat looks exactly like the first. This is the ledger format, the 4-step escalation ladder, and the habit that keeps it alive: log the count in the same action as the correction, never later.
Prerequisites
A place to write files the agent can read and edit. A person who corrects the agent often enough that repetition is possible. Nothing else — no database, no tooling.
If corrections are rare, skip this: a counter with 3 entries is overhead.
Steps
1. Create the ledger as one table. One row per distinct mistake, not per occurrence. Columns: identifier, short description, category, count, last occurrence, state, fix or escalation.
The description carries the class of error, not the incident. Concluded absence from a single spelling of a proper name is reusable. Did not find the supplier is not.
2. Fix the escalation ladder before the first entry. Deciding thresholds while looking at a specific mistake guarantees the threshold gets set to whatever excuses that mistake.
| Count | State | Action |
|---|---|---|
| 1 | log | entry written, nothing else |
| 2 | warning | propose a dedicated rule |
| 3 | systemic | write the rule, assign an enforcement level |
| 5 | critical | hard failure in review |
3. Make logging atomic with the correction. This is the step everything depends on. When a correction happens, the counter entry is written in the same action — not at the end of the session, not in a review pass.
Deferred logging fails for a structural reason: the moment you notice a mistake is the only moment you have full context on it, and it is also the moment you most want to move on.
4. Assign an enforcement level at the third occurrence. Writing a rule is not the fix. Text does not stop repetition on its own. At count 3, name how the rule is enforced:
L0 prompt text · L1 checklist in a skill · L2 build or hook check · L3 hard gate that fails
5. Link related classes. When a new entry resembles an existing one, say so in the row. Two mistakes that share a root cause should escalate together, and the resemblance is only visible while both are fresh.
6. Review on a fixed rhythm, not on impulse. Once a week, read only the rows whose count rose. That is a two-minute pass and it is the only moment the ladder actually gets applied — an escalation threshold that nobody evaluates is a number in a table.
The review also catches the opposite error. A row at count 4 whose last occurrence was three months ago is not an active problem; it is history, and leaving it in the live table inflates the sense of how much is broken. Archive it with its final count intact.
Verify
The counter works when you can answer, without reading the whole file: what is the most frequent class of mistake this month, and what enforcement level does it have?
Two health checks worth running monthly. Entries with count 1 and no recent date are probably one-offs — either merge them into a class or archive them. Entries at count 3 or more with enforcement level L0 are the real finding: a rule was written, nothing enforces it, and the count is still rising.
Troubleshooting
The ledger stops being written. The usual cause is that logging was separated from correcting. Re-couple them; a counter maintained in a weekly pass will be abandoned within a month.
Every entry is unique, nothing ever reaches 2. Descriptions are too specific. Rewrite them one level up — from the incident to the class.
The count rises and nothing changes. The ladder exists but has no executor. Escalation at count 3 has to be triggered by something other than goodwill, or the ledger becomes a diary of failures nobody acts on.