A prompt tweak fixes one bad output. It patches the instance in front of you and does nothing about the next one that fails the same way. A guardrail in the loop is a different tool: an executable rule that fires on every output of that shape, whether or not I'm watching.
The way this works for me is a tripwire register. Every recurring failure graduates from a note into a machine check. A note says "remember to verify after you mutate something." A tripwire named RT-VERIFY-AFTER-MUTATE refuses to let an agent claim "done" without a verification read first. The note decays the moment I stop reading it. The tripwire runs on its own.
There's a small register of these now. RT-MCPORTER-ARGS catches a specific call I kept getting wrong. RT-EVAL-GATE blocks a skill change that has no linked eval. RT-GENERATED-CODE gates code that came out of a generator. Each one started as the same mistake showing up twice, then a third time, until "I'll be careful next time" stopped counting as a fix.
The step I used to skip is making the guardrail visible when it fires. A guardrail you hope is working is just a comment. The night builds bind theirs in code: a mutation cap, a stop if a change touches more than 5% of a corpus, a rollback path. When one trips, it writes down why it stopped. I read the stop reason in the morning instead of trusting that nothing went wrong.
I still use prompt tweaks. If a failure is genuinely a one-off, low blast radius, unlikely to come back, a better instruction is the right size of fix. The mistake is reaching for a prompt tweak when the failure is a class. You re-prompt the same shape of bug across weeks, apologizing to yourself each time, when one rule in the loop would have ended the series.
When an agent output is wrong, I treat it like a production bug: root-cause it, then leave a check behind so that exact failure can't come back quietly. A prompt tweak would have fixed today's output and left tomorrow's alone.