I asked the AI to fix its own instructions: 1,771 incidents, 13 proposals

If you work with agents, this idea has probably crossed your mind: if the system records its own failures, it should be able to read the patterns and propose fixes to its own instructions. It improves itself, with you approving every change before it lands.

I built the whole thing, human approval included from day one. It works. I collected 1,771 incidents over three months and it produced 13 proposals.

And the system barely improved through that path. It didn't fail where you'd expect — neither the model nor the approval step was the problem — and that's the part worth telling, because the mistake sits at the design level and repeats in any system that tries to learn from its own logs.

The case that started it

It wasn't an abstract idea: it came from a concrete, repeated problem.

One of the system's skills had a habit of ending its runs with a question. Something along the lines of "shall I continue with the next part?". To the orchestrator, a run that ends waiting for input is a stuck run: it aborted the whole sequence.

I fixed it by hand, editing that skill's instructions. And while doing it I thought the obvious thing: this pattern is on record. The system knows this skill failed for this reason, several times over. Why do I have to be the one who notices?

The goal ended up written like this: replace the cycle human detects, human edits, human commits with the system detects, proposes a patch, the human approves with one click.

The constraint I set on day one

Before writing a line, I decided something I still consider the best decision in the whole subsystem: the routine never edits files or commits on its own.

Its output isn't a change, it's a proposal: the diff plus the reasoning behind it. It's stored in the database and waits. A human approves it and only then is it applied, or rejects it and it's archived.

The temptation to skip that is strong, because manual approval is precisely the bottleneck you're trying to remove. But a system that modifies its own instructions without supervision has no brake at all: if the criteria it judges by are wrong, every iteration makes them worse, and there's nothing outside the loop to catch it.

Four phases, all implemented

The design ended up in four parts, and all four are running:

• A unified incidents table, consolidating signals that previously lived scattered: orchestrator surrenders, skills that stall waiting for input, pre-flight checks that fail.
• Recurring-pattern detection: it groups by skill and reason, and flags anything appearing three or more times in seven days.
• The routine that proposes the patch, which decides whether the fix belongs in the skill's instructions or in code, computes the diff and persists it.
• The approval interface, with a 24-hour limit so the same proposal doesn't come back over and over.

None of this is broken. It all runs.

The numbers, three months later

When I went to measure the outcome, this is what I found:

• 1,901 incidents recorded in total.
• 1,771 of them still open, unprocessed.
• 13 proposals generated across the system's entire history. Seven approved, six rejected.

Thirteen. In three months, with nearly two thousand incidents of raw material.

And what stings most is that the most frequent incidents are exactly the ones you'd want to turn into rules. Over fourteen days: 351 repeated reads of the same file, 154 searches that found nothing and 151 failed commands. All actionable patterns. All sitting there, unprocessed.

Where it failed, which isn't where you'd expect

My first reaction was to assume the model wasn't up to the task. That's the comfortable explanation, and it was wrong.

The loop doesn't fail at the intelligent part. It fails in the plumbing. The hypotheses I still have open — and haven't finished ruling out — are three, and none of them involve the model's capability:

• That the proposal routine is barely firing at all, because of how its scheduling ended up configured.
• That the recurring-pattern view isn't grouping correctly, so it finds nothing to report.
• That the threshold of three occurrences in seven days is unreachable — not because patterns don't repeat, but because there's so much background noise that the real cases get diluted.

That last one interests me most, because it implies the problem isn't detection but signal quality. If the inefficiency detector produces false positives at scale, it doesn't matter how good the next stage is: you're asking it to find patterns inside a pile of noise.

So the next step isn't improving the routine that proposes patches. It's triaging the 1,771 open incidents and answering something more basic: how many are real signal and how many are noise from the detector itself. If the bulk is noise, detection has to be tightened before asking anyone for proposals.

What I took from this

A self-improvement loop doesn't fail for lack of intelligence. It fails in the plumbing, which is the part nobody shows in demos.

Recording signals is easy and cheap, which is why it's the first thing you build. It feels productive: the numbers go up, the table fills, it looks like the system is learning. Turning that signal into action is the real work, and it's exactly where the project stalled.

Accumulating 1,771 incidents without processing them isn't telemetry. It's an expensive log that looks like a dashboard.

I now apply the lesson before instrumenting anything new: if I can't say what decision someone — or something — will make with that data, the instrumentation can wait.

The second time the data contradicted me

This was the first result that forced me to go look at the database instead of trusting what I thought was happening.

A month later I did the same with the rest of the system, in a general review aimed at improving pipeline speed. I had a diagnosis put together and a plan written on top of it.

The data made me throw that plan out the same day. That's what the next entry is about.