Journal · The AI Architect · 2026-08-27
Send it to yourself first. See exactly what an automation produces before you point it at anyone real.
Send it to yourself first. See exactly what an automation produces before you point it at anyone real.
The uncomfortable truth about automation is that it does exactly what you told it to do, not what you meant. Those are rarely the same thing. The gap between them is invisible until it lands in someone else’s inbox, and by then you’re not debugging a workflow anymore, you’re apologizing to a customer or explaining yourself to a colleague.
The gap between intention and output
When you build an automation, you’re working from a mental model of what should happen. The trigger fires, the data flows, the message goes out, everyone’s happy. But mental models are optimistic by nature. They skip the edge cases because you’re not thinking about edge cases, you’re thinking about the happy path.
The customer whose name has an apostrophe in it. The order that comes in at 11:59 PM and gets timestamped for the wrong day. The merge field that pulls “undefined” because a database entry was empty. None of these show up when you’re picturing the automation in your head. They only show up in the actual output, sitting in an actual inbox, formatted exactly as the system chose to format it.
This is why testing on yourself isn’t a formality. It’s the only way to see the thing as it actually is instead of as you imagine it. Reading a workflow diagram tells you what should happen. Receiving the email tells you what does happen.
Try this: before any automated message goes to a real recipient, run it through with your own contact information at every stage — your email, your phone number, your account. Don’t just check the first message. Check the follow-ups, the reminders, the edge-case branches. Let the whole sequence play out on you.
Reading it like a stranger would
There’s a second layer to this, past just catching technical errors. Even when the automation works perfectly — no broken fields, no formatting glitches — it can still feel wrong. Tone is not a bug that shows up in testing logs. You have to actually read the message and ask whether a real person, with no context about how it was built, would feel respected by it.
This is harder than it sounds, because you know why the automation exists. You know it’s saving time, reducing errors, handling scale you couldn’t handle manually. That context makes you generous toward the output. The recipient has none of that context. They just see the words.
Send yourself the automated appointment reminder and read it at a moment when you’re not thinking about the business logic behind it. Does it sound like a person wrote it, or like a system executed it? Is the urgency appropriate, or does a routine confirmation read like an emergency because someone left the exclamation points on default? Small mismatches in tone are the fastest way to make an automation feel cold even when it’s technically correct.
Try this: wait a day after building the automation, then read your own test message fresh, as if you’d never seen the workflow behind it. Distance helps you notice things that familiarity hides.
Testing the sequence, not just the message
The final piece is that automations rarely send one message. They send a sequence, and sequences have their own failure mode: they don’t know what already happened. A welcome email goes out, then a follow-up two days later assuming no response, but the person already replied, already bought, already unsubscribed. The system doesn’t know that unless you built it to check, and you won’t know it doesn’t know until you watch it happen to your own inbox.
This means testing isn’t a single send-and-check. It’s living inside the sequence long enough to see how it behaves over time, especially when you interrupt it. Reply early. Take the action the automation is waiting for, then see if it notices. Unsubscribe halfway through and confirm it actually stops.
Try this: run the full sequence on yourself, but deliberately break the expected path partway through — reply, click, unsubscribe, whatever the “wrong” order looks like. If the automation adapts gracefully, you’re in good shape. If it barrels ahead anyway, you’ve found the thing that would have embarrassed you in front of a real customer.
None of this eliminates the need for judgment. Testing on yourself won’t catch everything, and it isn’t a substitute for thinking carefully about who’s on the other end. But it closes the biggest, most avoidable gap — the one between what you assumed would happen and what actually does. The book goes further into how to build these testing habits into your workflow permanently, so they stop feeling like an extra step and start feeling like just how you work.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.