Diagnose before redesigning — identify whether trigger, condition, or action broke before changing anything
When an agent fails, diagnose which component broke—trigger (never activated), condition (activated but context wasn't right), or action (executed but too vague/complex)—before attempting any redesign.
Why This Is a Rule
Agent failures have three distinct root causes, each requiring a completely different fix. Trigger failure: the trigger event occurred but you didn't notice it — the agent never activated. Fix: increase trigger salience (Agent triggers must be observable or measurable — vague triggers like "when I feel ready" never fire reliably). Condition failure: you noticed the trigger but the conditions blocked firing — the context wasn't right. Fix: adjust condition scope. Action failure: the trigger fired and conditions matched, but the action was too complex, vague, or effortful to execute. Fix: simplify the action (When an agent fires below 80% after 30 days, simplify before sophisticating — unreliable agents need reduction, not enhancement, Start every new agent at under two minutes with zero preparation — automaticity requires low activation energy first).
Applying the wrong fix wastes effort and may make the agent worse. If the trigger isn't salient enough (trigger failure) but you simplify the action (wrong fix), the simpler action still never executes because the trigger never activates it. If the action is too complex (action failure) but you make the trigger more visible (wrong fix), you now notice more opportunities to fail at the action, which increases frustration without improving performance.
This is root cause analysis applied to behavioral systems. The same principle that makes engineers trace bugs to the specific failing component before patching applies here: diagnose, then treat.
When This Fires
- Every time a behavioral agent fails — before attempting any modification
- During failure log review (Log every agent misfire with date, name, event, and hypothesis — weekly pattern review turns failures into redesign data) when analyzing patterns
- When an agent has been failing and you're about to redesign it — pause and diagnose first
- Complements Diagnose failing behavioral agents by component — trigger salience, condition scope, or action effort each require different fixes (two-week diagnosis) with a per-failure diagnostic framework
Common Failure Mode
Redesigning the entire agent after a failure: "My morning routine doesn't work, let me build a completely new one." Most failures are single-component issues. Rebuilding from scratch discards the components that were working and introduces untested new components. Diagnose the specific failure, fix that component, and preserve the rest.
The Protocol
(1) When an agent fails, ask three diagnostic questions in order: (2) Trigger check: "Did I notice the trigger event when it occurred?" If no → trigger failure. The event happened but didn't activate the agent in your awareness. Fix: increase salience (visual cue, alarm, environmental placement). (3) Condition check: "I noticed the trigger — did the conditions allow firing?" If no → condition failure. The trigger activated but context blocked the agent. Fix: broaden conditions or redesign for the context that actually occurs. (4) Action check: "Trigger fired, conditions matched — did I execute the action?" If no → action failure. The behavior was too complex, vague, or effortful. Fix: simplify (When an agent fires below 80% after 30 days, simplify before sophisticating — unreliable agents need reduction, not enhancement, Start every new agent at under two minutes with zero preparation — automaticity requires low activation energy first). (5) Apply only the fix for the diagnosed component (Change one agent component per iteration — multi-variable changes destroy causal attribution of what worked).