Write all three components of default agents — even…
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.
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…) — 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.