Applying a correction and moving on only changes the current output — it does not change what the agent believes next time. The fix has to go into the standing rules the moment it happens, not at the end of the session.
The single most expensive thing I do to an agent I am working with is correct it twice for the same thing. Not because the correction itself takes long — it is usually a sentence — but because if I have to give it again, that means the first one evaporated, and evaporated corrections are the main reason working with an agent for a week can feel like starting over every day.
The instinct, when a correction lands mid-task, is to just apply it and carry on. Fix the thing, move to the next thing, keep momentum. That instinct is exactly what loses the correction, because applying it and carrying on only changes the current output. It does not change what the agent believes the next time a similar situation comes up, because nothing about the belief was written down anywhere durable.
What actually works is writing the correction into the standing rules in the same turn it happens — not at the end of the session, not in a batch cleanup pass, right then, before the next thing distracts from it. And it has to be written as a rule with a reason attached, not just a bare instruction. "Do not do X" with no explanation gets argued away by whichever future pass finds it inconvenient, because an instruction with no visible reason looks arbitrary, and arbitrary instructions are exactly the ones that get quietly dropped under pressure to finish something else.
The reason should point at what actually happened, concretely — not "be more careful with destructive commands" but the specific command, the specific moment, the specific cost. A vague rule generalises badly and gets reinterpreted every time someone reads it. A rule tied to a real incident is legible even to a reader who was not there, and it survives being paraphrased by whatever later pass has to summarise the rules file for itself.
This is also the point where waiting for session end fails even when you are diligent about it. A long session accumulates a dozen small corrections, and by the end you either remember all of them accurately, which is unlikely, or you write up the memorable few and lose the rest to the same fog that made you need the correction in the first place. Writing it down at the moment it happens has no fog to lose it to, because there is no gap between the event and the record.
The other way a correction fails to stick is by being written too narrowly. If the mistake was reaching for one specific destructive command and the rule I write names only that command, the same mistake reappears a week later wearing a different flag, and technically nothing was violated. A correction that only covers the exact instance that produced it is a patch, and patches do not generalise; the rule has to name the property that made the instance wrong — irreversibility, or a claim made without checking it — so that it still applies to the next thing carrying that property and looking nothing like the first. That is harder to write than the narrow version, and it is the difference between a rules file that gets shorter and sharper over time and one that accretes forty near-identical entries, each covering one case, none of them covering the case in front of you.
The test I use now is simple: if I have said something once, would I be annoyed to say it again? If yes, it was never a one-off comment, it was a rule, and it should already be somewhere the next session reads before it acts, rather than somewhere I have to remember to bring up myself.