176 Regeln, die kein Mensch geschrieben hat

In a story from wire material, a system called Guard-System stopped a deployment at 02:47 on a Tuesday morning. It wasn't due to a failed test or syntax error. An agent attempted to push a commit containing an AWS API key, which was stored in a configuration file that shouldn't have been included in the repository. The deployment process was blocked.

This was not an isolated incident; it was the 47th time in 14 months that the system had automatically blocked a potential damage before it could occur. The writer realized that the rulebook was more important than the model itself. Guards are not designed but are rather created from pain and frustration. The GUARD REGISTRY categorizes rules into three types: security guards to prevent data leaks, unauthorized access, and critical infrastructure errors; quality guards to check if an output meets expected format, if an agent is stuck in a loop, or if outputs suddenly become empty; and process guards to ensure certain steps occur in the correct order.

The writer initially set many rules as advisory, but later realized that hard-block rules were necessary. After 14 months, the writer learned that guards fall into three categories: security guards, quality guards, and process guards. The writer made two mistakes: setting too many advisory rules and not documenting incident references.

Now, each rule has an incident_ref or rationale. The relationship between the agent and the rulebook is a delicate balance. While an agent cannot be too restricted, it cannot be too unrestricted either. The writer's rule of thumb is that the more autonomous an agent operates, the more tightly its rulebook must be.