The Close Call That Became a Hard Rule

Tuesday morning I almost double-emailed every subscriber on the Mentor Lab list.

Not because I misclicked. Not because I copy-pasted the wrong segment.

Because two automated tasks tried to do the same job at the same time, and neither one knew the other was already on it.

I caught it with 55 minutes to spare.

This is the full story: what happened, why it would have kept happening, and the three rules I locked in permanently so it can never happen again.

—

The Morning I Found Two Copies

At 9:00 AM, I ran a quick check on the email broadcast pipeline.

The check does one thing: it counts how many email blasts are scheduled to send today.

The answer should always be exactly 1.

Tuesday morning the answer was 2.

Both blasts were addressed to the full Mentor Lab list.

Both had the same content.

Both were set to fire at 10:00 AM.

If both had sent, every subscriber would have gotten the same email twice, a few minutes apart, from the same sender.

I had 55 minutes to fix it.

—

What the Broadcaster Does

The Mentor Lab series ships one piece of content every weekday at 10:00 AM across LinkedIn, Instagram, Facebook, YouTube Shorts, and email.

The email side of that runs through an automated system on our server.

Its job is simple: set up each day's email blast, load in the right content, and schedule it for 10:00 AM.

Every weekday at 9:55, a morning task fires and does that job.

That worked fine.

Until something set up the blast before the morning task ran.

—

How the Duplicate Got Created

Monday: the manual fix

On Monday I went in and corrected a mistake in one of the earlier emails in the series.

The script I used to make that fix also, as a side effect, went ahead and set up Tuesday's email blast.

Right content. Right time. Everything looked correct.

That was the email that should have sent.

Tuesday at 9:55: the morning task fires anyway

The next morning, the morning task ran on its regular schedule.

It had no way of knowing Tuesday's blast was already set up.

So it set up a second one.

Same content. Same list. Same send time.

Now there were two live email blasts, both aimed at every subscriber on the list, both ready to fire at 10:00 AM.

Neither one knew the other existed.

The catch

At 9:00 AM, the audit found both.

I deleted the second one through the email platform, confirmed the original was still in good shape, and let it send as normal at 10:00 AM.

No subscriber got the same email twice.

Time between the morning task creating the duplicate and me finding it: about 65 minutes.

Time left before both would have fired when I caught it: about 55 minutes.

—

Why It Would Have Kept Happening

The root cause was simple.

The morning task was built to create a new email blast every weekday, no conditions, no checks, no questions asked.

Whatever happened the day before, whatever was already set up, it ran and created a new one.

That design worked fine in a world where nothing ever touched the broadcaster except the morning task.

But the moment anything else set up a blast out of schedule — a manual fix, a retry, a test run, a script called directly — the morning task would create a duplicate the very next morning.

And it would keep doing it.

Every week. Every time.

I happened to catch it because I ran the audit when I did.

That is not a system. That is luck.

—

The Fix

Three changes, all permanent.

Change 1: Set up the whole week on Sunday

A new script runs every Sunday night.

It creates all five email blasts for the coming week in one pass.

Each blast is tagged with the drop name and the send date. Before creating a blast, the script checks whether one with that tag already exists.

If it does not exist, the script creates it.

One blast per drop per date. That is enforced at the creation step, not assumed.

Here is the logic in plain terms:

For each drop this week:
  Check if a blast for this drop + this date already exists
  If yes: skip it, move on
  If no: create it

No matter how many times that script runs, no matter what else touches the broadcaster, only one blast per drop can exist.

Change 2: The morning task becomes a checker

The weekday morning task no longer creates anything.

Its entire job is now to read the existing blast, confirm it is scheduled correctly, and send an alert if something looks wrong.

That is all it does.

It cannot create a blast. It cannot change a blast. It reads and reports.

Here is what it checks:

Read today's scheduled blast
Is it scheduled? Yes / No
Is it set for the right time? Yes / No
If anything looks wrong: send alert immediately
If everything looks right: log "OK" and stop

Separating the creation job from the checking job means neither one can accidentally do the other's work.

Change 3: Automatic check before every send

Right before each send window, a separate check runs.

It counts how many blasts are scheduled for today's date.

The answer must be exactly 1.

If the count is 0: alert — nothing is going to send.

If the count is 2 or more: delete the extras and alert immediately.

This runs automatically, every day, before every send. It does not depend on anyone remembering to check. It fires on schedule and tells me if something is wrong while there is still time to fix it.

—

The Three Rules, Now Hardcoded

These are written into the broadcaster and into the memory file that every future version of the system reads on startup.

Before any blast is created, check for one that already exists with the same name. If it exists, skip creation. This makes the setup process safe to run any number of times without producing duplicates.

The weekday task never creates, never changes, never writes. It only reads the existing blast and checks that it is correct. The Sunday batch script is the only process authorized to create blasts. One job each, kept separate, enforced at the code level.

The count of scheduled blasts for today must always be exactly 1. Any deviation triggers an immediate alert. Manual checks are luck. An automatic pre-send audit fires every time, at the same point, with a clear pass or fail.

—

Why This Pattern Shows Up in Every Automated Workflow

If you are a coach, a consultant, a course creator, or a service provider running any kind of automated workflow, you will hit a version of this.

It does not have to be an email broadcaster.

It could be two AI agents working on the same client file at the same time.

It could be a form submission getting processed twice because the platform retried on a slow response.

It could be a payment getting charged twice because a customer hit submit, the page froze, and they hit it again.

The pattern is always the same.

Two tasks. One shared job. No coordination between them.

And the failure mode is always the same.

Both tasks succeed. Both records exist. Neither one knows the other is there.

Make setup smart enough to skip work that is already done. If a task creates something, it should check first whether that thing already exists. If it does, stop. If it does not, proceed.

Separate the task that creates from the task that checks. A task that both creates and verifies will eventually create twice when the verification step misfires. Keep them separate. Give each one exactly one job.

Audit before the moment of consequence. A human sanity check before the send, the invoice, the campaign launch is the right instinct. But a human check only fires when someone remembers. A built-in pre-action audit fires every time, at a consistent point, with a clear result.

One close call becomes a permanent rule. That is the only way a system gets more reliable over time.

—

What Is Running Now

The broadcaster is running all five drops this week on this architecture.

The morning check has passed clean every day.

No subscriber has received a duplicate.

The system is more reliable now than it was before the incident, because the incident forced a structural fix instead of a mental note.

—

What Is Next

The next email in this series breaks down the 7-gate quality check that every Mentor Lab piece clears before it enters the broadcaster.

Context brief. Framework selection. Persuasion scoring. Reading-level check. Voice match. Trust and social proof review. Final panel pass.

Every piece runs that gauntlet before it schedules.

If you want the full playbook as it comes out, including the broadcaster architecture, the duplicate-check logic, and the pre-send audit, the Mentor Lab is open now.

—

*Sam Bell III is the founder of Social Ads Mentor and PPC Boutique. He runs a real ad agency on a ten-agent AI fleet and documents the infrastructure publicly through The Mentor Lab.*

Join here: https://1fb.me/lab-skool

Join The Mentor Lab on Skool