Name the schema before building the agent — a reliably firing agent built on a wrong model produces systematic errors

Why This Is a Rule

Every behavioral agent embeds a model of how the world works — a schema that determines what the agent "expects" to happen. An agent that says "When I receive criticism, pause for 10 seconds before responding" assumes that your initial reaction to criticism is unreliable and that a pause improves response quality. If this schema is correct, the agent works well. If your initial reactions to criticism are actually well-calibrated (perhaps you've done extensive emotional regulation work), the agent adds unnecessary friction to functional behavior.

The danger is that agents automate behavior without ever making their underlying assumptions explicit. A "check email only at 10am and 4pm" agent assumes that real-time email responsiveness isn't critical for your role. If that assumption is wrong — you're in a support role where response time matters — the agent reliably produces bad outcomes: missed urgent messages, frustrated colleagues, damaged reputation. The agent fires perfectly while the schema is wrong.

Making the schema explicit before building the agent creates a checkpoint: "Does this model of how the world works actually match my situation?" If yes, build the agent confidently. If the schema is questionable, test it before automating behavior based on it.

When This Fires

• Before designing any new behavioral agent — as a mandatory pre-design step
• When an agent fires reliably but produces bad outcomes — the schema may be wrong
• When importing someone else's behavioral system (a book's advice, a coach's recommendation) — their schema may not match your context
• During periodic agent reviews when reassessing whether the underlying model still holds

Common Failure Mode

Importing agents without examining their schemas: "Tim Ferriss batches email twice a day, so I should too." Ferriss's schema: his business doesn't require real-time email responsiveness, and batching frees cognitive resources for creative work. Your schema may be different: your role may require fast responses, and the anxiety of unanswered email may consume more resources than processing them does. The agent is the same; the schemas are different; the outcomes will be different.

The Protocol

(1) Before building an agent, write one paragraph: "This agent assumes that..." — state the model of the world that makes this agent's design rational. (2) Evaluate: is this model accurate for your specific situation? Not "is this generally true?" but "is this true for me, now?" (3) If the schema is clearly correct → build the agent. (4) If the schema is questionable → test it first. Run a one-week experiment where you observe the relevant dynamics before committing to automation. (5) Review the schema periodically — contexts change, and a schema that was accurate last year may not be now. When the schema changes, the agent built on it needs redesign.