Instruction based guardrails for agents fail for a simple reason: the constraint and the attacker live in the same context window. A prompt that says "don't exploit, only report" is text the model can be argued out of. Safety that is enforced only inside the prompt is not really a guardrail.
this is fine for vibe-coded projects with non-critical production workloads, where downtime doesn't actually affect your users or you.
nobody's losing sleep if the site is down for 10 seconds.
but this can't be applied to projects with an SLA, where every minute you're down literally costs you money.
we've already seen examples of ai agents breaking critical features in products used by the whole world.
and once that happens it's not just the downtime, it hits your reputation and it changes what users expect from you.
there's a reason big companies run staging environments and don't let anything touch prod directly.
it's not because they're slow or scared, it's because the cost of getting it wrong is real.
in general this whole approach is fine for tiny little saas projects, mainly b2c, where you're the only one who feels the pain if something breaks.
anything bigger and you need guardrails.
Takeaway: treat output correctness as a first-class signal, not a postmortem artifact. Until you can page on "the agent got dumber," cost and latency graphs are measuring the wrong thing precisely.
Production AI agents have decent tooling for cost and latency but not much for quality. You can prove your agent is fast and cheap, you can't prove it's still correct. This is where silent degradation happens.