Only automate decisions that are frequent, stable…
Design agents only for decisions that score high on frequency (recurring often), stability (same answer each time), and low individual stakes, because these three properties determine whether automation saves resources without introducing unacceptable risk.
When This Fires
- When considering whether to create a behavioral rule, default, or automated decision
- During cognitive load audits when identifying which recurring decisions to offload
- When someone suggests "let's just make a rule for this" — check the three criteria first
- When evaluating existing automation that seems to be producing poor results
Common Failure Mode
Automating decisions that are frequent and low-stakes but unstable: "I'll always say yes to coffee meetings." The frequency and low individual stakes make this feel safe to automate, but the optimal answer varies — some meetings are valuable, some waste hours. The automation removes the deliberation that would distinguish valuable from wasteful, and the accumulated cost of indiscriminate yes-saying is high even though each individual meeting seems low-stakes.
The Protocol
(1) For any decision you're considering automating, score three dimensions: Frequency: does it recur at least weekly? Stability: would you give the same answer >90% of the time? Stakes: is any single instance easily recoverable if wrong? (2) All three must score high. If any dimension scores low, keep the decision deliberative. (3) For decisions meeting all three criteria, design the automation: specify the trigger, condition, and default action. (4) Build in a review cadence: even well-designed automation can become outdated as context changes. Quarterly check: is the decision still frequent, stable, and low-stakes? (5) When in doubt, err toward deliberation. The cost of unnecessary deliberation is time; the cost of inappropriate automation is systematically wrong decisions you don't notice.