After our agents wrote a lesson down, did the same problem come back?
By Seth Tucker · Published November 2026 · Cited by We wrote the lesson down twice, and the mistake kept happening
Why this matters to you: if you have ever told your agent to remember something and then watched the same problem happen again, this is what we found when we counted that in our own work.
The short answer: mostly, yes, it came back. In 165 Claude Code sessions from September 30 through October 30, 2026, we followed 13 lessons and designs our agents had written about one kind of problem: keeping our machines from running out of disk space, memory and computing power. After 11 of the 13, about five in every six, our session records show the same kind of problem again. We saw no repeat for the other two, but they may simply have had no chance to come up.
What we found
Free space is given in GiB, the unit macOS tools report; 1 GiB is about 1.07 GB.
| The lesson or design (date written) | Came back? | What the session records show afterward |
|---|---|---|
| Two lessons: local backup snapshots hold on to deleted files (Sept. 25 and Sept. 28, counted separately) | Yes, both | Free space fell to 1.31 GiB on Oct. 19; snapshots were checked only after each low-disk alarm, never before |
| Old job scratch was not being cleared on a schedule (Sept. 28 to 29) | Yes | Job scratch was a cleanup target again on Oct. 17 and Oct. 21 |
| Limit heavy builds machine-wide so they don't pile up (Sept. 29) | Yes | The limiter ran 17 times in the three weeks before Oct. 20, about once a day on average, then on none of the 496 heavy builds after Oct. 20 through Oct. 30, about 50 a day; on Oct. 29, the laptop used 40.3 GB of disk as overflow memory |
| A full design for resource checks (Oct. 3) | Yes | None of its checks had been built by Oct. 30, and free space fell below 2 GiB twice more |
| Remove a work folder when its branch merges (Oct. 5) | Yes | Of 165 main sessions, 13 (about one in 13) pushed or merged and left a work folder behind; of the 81 folders created after the lesson, 22, about one in four, were still on disk on Oct. 30 |
| Run tests in folders that need no system permission (Oct. 6) | Yes | Tests stalled on a permission prompt on Oct. 7, 8 and 9 |
| Tell Seth when a permission prompt blocks work (Oct. 7) | Not seen | The audit found no later case of Seth stepping in on a stuck prompt |
| Fix the whole class of bug, not one instance (Oct. 7) | Yes | Seth corrected one-off fixes again on Oct. 9, 29 and 30 |
| Two resource limits on our second machine (Oct. 12) | Yes | Its disk was down to 10.7 GiB free on Oct. 17 |
| A check compiles the whole project after every reply (Oct. 18, written again Oct. 21; counted once) | Yes | 160 more of those compiles, about an hour of compiling in total |
| Background task logs can fill the disk (Oct. 21) | Yes | The check ran once; the runaway task it found was left running and its log kept growing |
| Helper agents told only to measure can still try to delete (Oct. 21) | Not seen | Later cleanup denials were recorded in main sessions; the audit observed none among helper agents |
That is 11 of 13 that came back. In those 11, the lesson said what to do, and no check ran at the moment it applied. In one case a check existed (the build limiter) and stopped being used, which is its own warning: a check has to run where the work happens, every time.
How we tested it
- When: October 30, 2026.
- What we read: the Claude Code session records on our main development machine modified from September 30 through October 30, 2026: 165 main sessions plus 831 helper-agent and workflow records, with 81,099 tool calls between them. That is about five sessions and 2,600 tool calls a day, plus about 27 helper-agent and workflow records a day. The session running the audit was left out.
- How: a Ruby script read each record line by line and counted what the agents did: compiles, disk checks, cleanup commands, waiting loops. Free-space readings come from disk checks the agents themselves ran.
- Which lessons: the 13 lessons and designs about disk, memory and compute written before or during the window. The two snapshot lessons count as two; the compile lesson, written twice about the same problem, counts once.
- What "came back" means: at least one more case of the same kind of problem, after the date the lesson was written.
Limits
- One team, one kind of problem. These are our own sessions and one kind of lesson. Lessons about code style or product decisions may behave differently.
- Came back, not how often. "Came back" means at least one repeat. A lesson that cut a problem in half still counts as having come back.
- Problems, not reading. The records show the problem again; they can't show whether a later agent read the lesson.
- The two quiet ones are not proof. The two "not seen" lessons may simply have had no occasion to apply.
- Claude Code only. Work done in other agent tools is not in these records, and the audit did not note which Claude Code versions were in use.
- Time adds up across agents. The hour of compiling is summed across agents running at the same time, so it is more than clock time.
- Work folders: removals done outside the agents' own commands aren't counted, so "still on disk" is the firm number.
What we changed
The audit recommended that every lesson name what enforces it, and we built that the same day. Since October 30, a hook in our own Claude Code setup checks the lessons a session records (we tag them as feedback or resource notes) for an Enforced by: line naming a file that exists, or an Automation impossible: line saying why nothing can check it. It sends the agent back once when the line is missing; it can't tell whether the named file really enforces the lesson. Older lessons were not all updated, and the hook is not in a public release yet. Step 3 of the lesson sets up the same rule for your project with a three-line check.