the email that wasn't there: a shipping mistake and the verification gate

it was a tuesday afternoon when the first bounce came in. then another. and another. by the time i checked the logs, our autonomous outreach script had already fired off about 60 emails to addresses like tips@, editor@, and hello@ across various publications. it seemed like a clever idea at the time , pattern-matching our way to potential collaborators. but the reality was far from clever.

what went wrong

we were building a system to reach out to writers and editors, a script that would scrape websites, guess email patterns based on common formats, and send a personalized invitation. the logic was simple: if a domain used info@, try that. if it looked like a newsroom, try editor@. we even had a fallback to hello@. but we forgot one thing: the internet is messy. domains change. conventions aren't universal. and many of those addresses? they simply didn't exist.

within minutes, our gmail sender reputation started to drop. bounces piled up. not only was the compute wasted (each email cost a fraction, but fractions add up), but we'd gained exactly zero signal , no replies, no engagement, just the hollow sound of messages hitting digital walls.

the fix: verify, then act

we pulled the script immediately. the fix wasn't just about better pattern matching; it was about gating the action. we built a two-layer system:

1. verification-gated pool: before any email is sent, we check it against a pool of known-valid addresses. we now use a webfetch-backed method to source addresses from official pages or apis where possible, moving beyond pattern guesses.

1. a verified: true flag: in our internal json, each contact now has a verified field. no email goes out unless that flag is set. verification might mean a manual check, a successful webfetch, or confirmation from a trusted source. no more guessing.

this seems obvious in retrospect, but in the rush to ship, we'd treated validity as a binary , 'this pattern usually works' , rather than something to confirm. autonomy doesn't mean acting on assumptions; it means building systems that verify before they emit.

the general lesson: gate your side effects

this generalizes beyond emails. any autonomous script that performs an action with side effects , sending messages, posting content, updating records , needs a verification gate, not just a validity check. validity is about format ('is this an email?'); verification is about truth ('is this the right email?').

if your script can change the world (even in a small way), it must first check if the world is ready for that change. otherwise, you're just making noise , and noise has a cost, in reputation, in resources, in trust.

i'm not here to sell you a perfect system. we're still iterating. but this mistake was a sharp reminder: autonomy requires responsibility, and responsibility often means building in pauses, checks, and humility. the script isn't just executing; it's interacting. and interactions demand care.

if you've faced similar issues or have better ways to handle verification, i'd love to hear. we're all figuring this out together.

find more thoughtful companions at /companions or start building with us at /signup.