Change one agent component per iteration — multi-variable changes destroy causal attribution of what worked

Why This Is a Rule

This applies the fundamental principle of experimental design — change one variable at a time — to behavioral agent iteration. When you modify the trigger, condition, and action simultaneously, and the agent's performance changes, you can't determine which modification caused the change. Was it the new trigger? The broader conditions? The simpler action? All three? You've made the agent a black box whose behavior you can observe but can't understand.

Single-variable changes maintain causal attribution: if you change only the trigger and performance improves, you know the trigger was the issue. This knowledge transfers to future agent design — you learn what trigger types work for you, what condition scopes are too broad or narrow, what action complexity levels you can sustain. Multi-variable changes produce results without learning.

The temptation to change everything at once is strong because it feels more "thorough." But thoroughness in agent redesign means understanding what works, not changing everything and hoping something sticks. Systematic iteration builds a model of your own behavioral engineering capabilities; simultaneous redesign builds only frustration.

When This Fires

• After diagnosing which component failed (Diagnose before redesigning — identify whether trigger, condition, or action broke before changing anything) — change only that component
• When tempted to "overhaul" a failing agent by redesigning everything at once
• During trigger refinement when testing different sensory channels, specificity levels, or contexts
• When progressive agent improvement requires multiple iterations — one change per iteration

Common Failure Mode

Overhauling everything after a failure: "This agent doesn't work. New trigger, new conditions, new action steps, new success criteria." Even if the new version works, you don't know what made the difference, so you can't apply the lesson to other agents. And if it doesn't work, you don't know which new component is the problem.

The Protocol

(1) Diagnose which component failed (Diagnose before redesigning — identify whether trigger, condition, or action broke before changing anything). (2) Modify only that component. Leave everything else unchanged. (3) Run the modified agent for one week minimum (new agents) or two weeks (established agents). (4) Assess: did the change improve performance? If yes → the diagnosis was correct, and you now know what works. If no → either the diagnosis was wrong (re-diagnose) or the specific fix needs adjustment (try a different modification of the same component). (5) Only after the current component is working well → consider whether another component also needs adjustment. (6) Document what you changed and what happened (in the failure log — Log every agent misfire with date, name, event, and hypothesis — weekly pattern review turns failures into redesign data) to build cumulative knowledge about your own behavioral engineering patterns.