Write all three components of default agents — even 'condition: always' reveals indiscriminate firing patterns
When reverse-engineering a default agent, write down all three components (trigger, condition, action) even if the condition is 'always' or appears absent, because making the implicit condition explicit reveals where the default fires indiscriminately.
Why This Is a Rule
Default agents — the automatic behaviors you've accumulated through years of reinforcement — have the same three components as designed agents: trigger (what initiates the behavior), condition (when the behavior fires vs. doesn't), and action (what you do). But defaults often have degraded or absent conditions, meaning they fire indiscriminately whenever the trigger occurs regardless of context.
"When I feel anxious [trigger], I check my phone [action]" — where's the condition? It's "always." The agent fires in meetings, during deep work, in conversations, at dinner. The absence of a condition is itself the design flaw: the behavior was never consciously designed with appropriate scope limitations.
Writing "condition: always" forces you to see this indiscriminate firing pattern explicitly. The natural next question becomes: "When should this agent actually fire?" Perhaps checking the phone is reasonable during breaks but destructive during deep work. The redesigned agent gets a condition: "When I feel anxious AND I'm not in a focused work block or conversation, check my phone." The explicit condition turns an indiscriminate default into a context-appropriate response.
When This Fires
- When analyzing any automatic behavior you want to understand or change
- During behavioral audits when cataloging your existing default agents
- When a behavior keeps occurring in contexts where it's clearly unhelpful
- Before designing a replacement agent (Diagnose failing behavioral agents by component — trigger salience, condition scope, or action effort each require different fixes) — you need to understand what you're replacing
Common Failure Mode
Omitting the condition field when it seems absent: "Trigger: anxiety. Action: phone check. That's it." By not writing "Condition: always," you miss the diagnostic insight. The condition field is where you'll add the scope limitation that transforms the default from indiscriminate to context-appropriate. Leaving it blank treats the indiscriminate firing as a fixed feature rather than a modifiable parameter.
The Protocol
(1) Identify a default behavior you want to understand. (2) Write the trigger: what observable event or internal state initiates it? (3) Write the condition: under what circumstances does it fire? If you can't identify a condition, write "always" — this is the diagnosis. (4) Write the action: what specifically do you do? (5) Examine the "always" conditions: which of these contexts is the behavior appropriate in, and which is it harmful? (6) The gap between "fires always" and "should fire sometimes" is your redesign target — add the condition that the default agent lacks.