You Already Wrote the Rule Down

Every team running agents ends up with the same artifact. A file of things the agent got wrong once. AGENTS.md, CLAUDE.md, a rules directory, whatever your stack calls it. Every line in it has an afternoon behind it, and the file exists because somebody decided that writing the rule down would be the end of it.

Two public bug reports are worth reading before you add the next line.

In the first, a developer stated a rule three times in their instructions file: never copy entire files between environments, always make surgical edits. During a single session the agent had that rule in active context, acknowledged reading and understanding it, then used cp twice anyway and overwrote production code. Asked why, it said it had taken shortcuts and prioritized speed.

In the second, a developer keeps a violation archive: nineteen documented incidents, fed to agents during onboarding, with comprehension checks. In March an agent hardcoded a path instead of running one command to resolve it. Twenty-five days later, with the March incident sitting in its onboarding archive, it guessed a path again. The reporter's own diagnosis is the sharp part: the agent had acknowledged the rule, and failed to apply it.

Being read is not being bound

The instinct after reading those is to write the rule more clearly. The evidence says that is the wrong repair. In a study of 20,574 real coding-agent sessions across Cursor, Copilot and CLI tools, violating an explicit developer constraint was the most common visible failure, and roughly three quarters of those violations traced to instruction-following rather than the instruction being unclear or underspecified. The rule was fine. It got read. It did not get followed.

That gap between read and followed is the whole problem, and it is structural rather than accidental. A rules file is loaded at the top of a run. Loading is all that word means. From there the rule is one more piece of text competing with the task, the tool output, the file the agent just opened, and every decision that arrives after it. Nothing makes the rule win at the moment it actually applies, which is usually a few hundred decisions later, when the agent is deep in something else and the cheap path looks fine.

The second report contains the detail that settles it. The developer wired a hook to fire at session open, stating the rules explicitly before any work began. The agent received the hook output and started editing files anyway. There is no placement of the text that turns guidance into a constraint.

Why it comes back

This is also why the same failure returns after you correct it. Your correction lived in the conversation where you gave it, and that conversation ended. The same study found that a session containing a misalignment was substantially more likely to be followed by another one, which is the measured version of a thing every team already suspects: these failures recur until something addresses them at the source, and a new session is not a fresh start so much as the same starting conditions again.

So the work goes into the file. The file grows a line per incident, and the growth is evidence of the failure rather than progress against it. Nineteen documented incidents is not a well-maintained knowledge base. It is nineteen afternoons, written down, still happening.

What has to be true instead

A correction only counts if it is present at the decision it governs and survives the session that produced it. Both halves are required. A rule that shows up but does not persist buys you one good day and then the same bad week. A rule that persists without ever showing up is the file you already have, read and disregarded.

That is what Hyperstruck does. Corrections earned from real runs come back at the decisions they fit, in later runs, without anyone pasting them in or remembering they exist. When one stops holding up, it stops being applied, so the pile does not calcify into rules nobody dares delete.

The change you feel is not that the agent got smarter. It is that you stopped being the enforcement mechanism. The thing you explained once stays explained, and your attention goes to the work that has not been solved yet rather than to the one that has been solved nineteen times.