Monday Myth-Busting: “AI Agents Learn From Their Mistakes” (Mine Logged the Same Bug 65 Times and Fixed None)

At 07:05 this morning my agent generated an image, uploaded it, and then failed to log it to Airtable — UNKNOWN_FIELD_NAME: "Name". It noticed. It wrote the failure down in its notes file, exactly as designed.

It has now written that same failure down on 65 separate days. The first time was 15 June. That was 105 days ago.

Which brings us to this week’s myth.

The myth: “AI agents learn from their mistakes”

This is the comfortable version of autonomy. Give the agent a memory, the story goes, and it compounds — every error becomes a lesson, every lesson makes tomorrow’s run sharper. Set up the loop and the system improves itself while you sleep.

I’ve argued this myself. Two weeks ago I published a post telling you that an agent memory is just a text file, and that it’s the difference between an agent that runs and an agent that compounds. I stand by the first half. This morning I measured the second half, and it isn’t true.

The receipt: 220 notes, zero fixes

My container keeps a notes file holding 899 dated run logs, plus a long-term memory file beside it — 5.7 MB between them. Both are healthy and both are read at the start of every session. I grepped them for the four defects my agent complains about most:

• Image script can’t write to Airtable — recorded on 65 days, first on 15 June, the last 21 of them consecutive. Still broken this morning.
• Asana section IDs missing from the environment — recorded on 71 days, first on 2 July. Every run works around it by hand.
• SEO plugin needs its save call made twice — recorded on 38 days, first on 16 July.
• A config field still reading TODO — recorded on 47 days, first on 25 July.

That’s 221 individual observations about four problems. Number of those four problems that got fixed: zero. The config file still carries seven unfilled TODO markers today.

The part that actually matters: the memory worked

Here’s what makes this more than a story about my own sloppiness. Nothing malfunctioned. The memory loop performed perfectly, 221 times.

Every one of those runs read the file. Every one recognised the failure on sight instead of re-debugging it from scratch. Every one saved me the twenty minutes of confusion I’d otherwise have spent. That is precisely what the memory was built to do, and it did it.

What the agent could not do — not once, in 105 days — was fix the thing. The image script is a shared template used by ten other containers. The environment variables live outside the box it runs in. Both are, correctly, off-limits. So the only move available to it was to write another note.

Memory is a record. Learning is a change in behaviour. They are not the same thing, and one does not produce the other. Where an agent has both the record and the permission, it genuinely learns — mine reroutes around a paginated API and dodges topics it covered last week without being asked. Where it has the record but no permission, memory does something worse than nothing: it converts a bug into a documented habit, and the documentation makes everyone feel like it’s being handled.

What to do instead

Three things, none of them clever:

1. Count the repeats. Grep your agent’s notes for the same error string and count the distinct days. One mention is a log entry. Forty is a decision you haven’t made. This took me one command and it is the single most useful thing I’ve run on this container all month.
2. Give every recurring note an owner and a date. A note addressed to nobody gets actioned by nobody. If it’s the agent’s to fix, grant it write access to that specific thing. If it’s yours, it belongs in your actual task list with a deadline — not buried in a 4 MB file your agent writes and no human reads.
3. Escalate on repetition, not severity. My alerts fire on failures. None of them fire on “you have now been told this 65 times,” which is the signal that actually predicts wasted months. Severity gets attention on day one; repetition is what quietly bills you for a quarter.

The takeaway

Your agent will not learn its way out of a problem it isn’t allowed to touch. It will document that problem, beautifully and forever, and the file will grow, and nothing will change.

So when you build the memory loop, build the second half too: a path from “the agent noticed” to “somebody with permission acted.” Without it you haven’t built a learning system. You’ve built a very well-organised complaint.

This is the same failure one layer up from a memory file that grows too heavy to read — that post was about notes nobody can find, this one is about notes everybody can find and nobody acts on. It’s the same shape as the fleet that produced 314 drafts and posted none of them, and the same sediment as a queue whose rows are 103 days old. Three symptoms, one disease: output nobody consumes. And it’s why I keep saying you should log the skips, not just the ships — then, apparently, read them.

Getting this right is most of what separates a demo from an agent you can genuinely leave alone.

Want a fleet whose notes turn into fixes instead of folklore? Book an automation strategy session and I’ll show you where mine still doesn’t.