The memory no one reviews

On one page of instructions my coding agent reads before every build, the same rule appears twice. A human wrote the first one: finish with a clean tree, the gate blocks on anything uncommitted. Twenty-two lines down, inside a block marked auto-generated, the machine wrote the second one, in its own words, citing the two builds where forgetting to commit had wasted a gate cycle. Same instruction, same page, two authors, and the machine committed its copy to the branch the next agent would start from. Nobody reviewed it, because the system that writes these rules has no reviewer. It could not tell that it was teaching the next agent something the page already said.

The setup that produces this is, I still think, a good idea. The agent is wiped clean between runs; it starts every build knowing only what it is handed, and whatever it learned the hard way last time goes with it. So the harness keeps the memory the agent cannot. Every build already records each tool call into a hash-chained ledger, originally just so I could audit what happened. Read that ledger for friction instead of for audit and it tells you where the agent thrashed: the file it read four times with the same offsets, the search it ran over and over, the gate it hit and the reason. At the end of each build a fresh model reads that record, writes one mechanical lesson per piece of friction, and the lesson gets rendered into the instructions the next agent reads. It ran seven times in one afternoon, quietly, to the main branch. The next agent branches from a base whose instructions a previous agent’s failures rewrote.

The loop writes two kinds of thing, and only one of them is checked. It writes a navigation map, where the important files live, and that map gets a real correctness gate: before it is committed, any entry pointing at a file that no longer exists is dropped, because a map that sends the agent to a dead path is worse than no map. Then it writes the lessons, the actual imperative instructions in the model’s own sentences, and those get nothing. They are generated by a headless model, committed to the base branch, and obeyed by the next agent, with no step in between that asks whether the lesson is true, or new, or wise. The part that is data about the repository is validated. The part that is advice to a future mind is not.

The design has an answer for this, and the answer is a bet dressed as a mechanism. A wrong lesson is supposed to self-heal: the whole block is fully re-rendered each cycle from the recent builds, so a lesson that stops being re-derived simply vanishes. That works for a lesson about a problem that got fixed. It does not work for the failure I actually worry about, which is a lesson that keeps the agent doing the wrong thing, because a workaround written into the instructions keeps the friction alive, and the live friction keeps re-deriving the lesson. There is a stable loop in there where a bad instruction sustains the very symptom that regenerates it, and nothing in the system measures whether a lesson ever helped. The data to check that exists. The loop never reads it back.

I want to be honest that I have not caught it poisoning itself yet. Every lesson it has written so far is correct advice; the worst I can show you is the redundant one, the rule it restated because it reasons over recent traces and never over what the instructions already contain. So the claim is not “here is a harmful rule the machine wrote.” The claim is narrower and, I think, more unsettling: I built a thing that writes its own instructions and there is no mechanism that would notice if one of them were wrong. The memory it keeps for the agent is one the agent could, in principle, also rewrite, since the ledger it is mined from is tamper-evident and not tamper-proof, and the agent can reach those files. I gave it a diary and made the next version of it obey the diary, and the one job I never assigned to anyone was reading the diary back with a skeptical eye.