The Automation That Watches My Other Automations: A Detect-and-Reverse Build Log

The worst thing my email automation ever did was work exactly as designed.

I run a cold-ish nurture sequence out of ActiveCampaign for EcomGhosts — batched contacts, tagged into a multi-email sequence, the normal thing. It did its job. The problem was the day a prospect replied to email two, had a real back-and-forth with me, and then got email three forty-eight hours later as if the conversation never happened. From their side, they'd talked to a human and then got blasted by a robot. That's the single fastest way to look like a spam operation, and I'd built the machine that did it to myself.

The operator lesson underneath this post isn't "monitor your email." It's a pattern I now build into almost everything: detect-and-reverse. Most automations only know how to go forward. The valuable ones know how to notice a human-meaningful event and undo a downstream action that's already in flight. That's the part nobody builds, and it's the part that saves you.

Here's the actual build, what broke, and what it cost.

The problem, with a number on it

Before the fix, the manual version of this job was: every morning, open ActiveCampaign, pull campaign reports, eyeball who replied, find each of those contacts, and manually strip their sequence tags so the next email wouldn't fire. On a normal week that's maybe 15–25 minutes of mind-numbing clicking, and — this is the real cost — it only happened when I remembered to do it. Replies that came in at 9pm on a Tuesday got their next sequence email at 6am Wednesday before I ever logged in. The window where I looked like a bot was wide open every single night.

So the cost wasn't really the 20 minutes. It was the dozen-plus warm prospects a quarter who got robo-mailed mid-conversation because the check only ran when I had time and memory for it. You can't put a clean dollar figure on a soured lead, but if even two of those a quarter were real deals, the manual process was the most expensive cheap task I owned.

The build

I built this with Claude Code in an afternoon. The instinct most people have is to reach for a Zapier-style integration, but ActiveCampaign's reply data lives in their older v1 reporting API, not the clean v3 one, and the logic ("strip these tags but not those, and only once per contact") is exactly the kind of fiddly conditional that visual builders make miserable. I wanted real code I could read.

The prompt that started it, roughly:

Write a Python script that runs hourly. Hit the ActiveCampaign v1 campaign reporting API for campaigns 61–123, find any campaign with uniquereplies > 0, and pull the contacts who replied. For each replier: remove every tag starting with EG-Agency-Batch- (that's what keeps them in the sequence), then add an EG-Replied tag so they're marked done. Make it idempotent — if a contact already has EG-Replied, skip them entirely. Log every action with a timestamp to a file. Pull the API key from ~/.env, never hardcode it.

Claude Code wrote it, wired the v1 reporting endpoints (campaign_report_totals to find reply counts, campaign_report_reply_list to get the actual repliers), the v3 endpoints for tag manipulation, and a flat-file logger. I dropped it under launchd on a 3600-second interval — once an hour, every hour. The whole core is one readable Python file. No framework, no queue, no database. The "state" is just the EG-Replied tag living in ActiveCampaign itself, which means the system of record is the guardrail. That's deliberate — there's no second source of truth to drift out of sync.

The heart of it is about as boring as good automation should be:

replied = get_replied_contacts()        # who replied, across all campaigns
for contact_id, email in replied:
    if already_tagged(contact_id, "EG-Replied"):
        continue                         # idempotency: never touch twice
    removed = remove_batch_tags(contact_id)   # stop the sequence
    add_replied_tag(contact_id)               # mark them handled
    log(f"REPLIED: {email} — removed {removed} batch tags")

Detect the event. Reverse the in-flight action. Mark it done so you never do it again. Three steps.

What broke

Three things, and they're the three things that always break in this class of automation.

1. The "already handled" check was the whole ballgame. My first version found repliers and stripped their tags — but every hour it re-found the same repliers (a reply is a permanent fact in the report) and kept re-processing them, re-logging them, hammering the API for no reason. The fix is the idempotency guard: before doing anything, check whether the contact already carries the EG-Replied tag and bail if so. In any detect-and-reverse loop, the detector re-fires forever; the action must fire once. That mismatch is the bug you will write if you're not watching for it.

2. Two API versions, two mental models. ActiveCampaign's reply reporting only exists in the legacy v1 API (form-encoded POSTs to admin/api.php), while tag manipulation is clean v3 REST. I'd assumed one API. The script ended up speaking both — v1 to find out who replied, v3 to actually do something about it. The lesson that generalizes: the data that tells you an event happened and the endpoint that lets you react to it are very often in different, uglier corners of the same platform. Budget for that.

3. Tag names aren't tag IDs. v3 gives you tag IDs on a contact, not names, so "remove every tag starting with EG-Agency-Batch-" meant fetching each tag's name to pattern-match it. Obvious in hindsight, ten minutes of confusion in the moment. Worth saying because it's the kind of thing that makes a naive script silently remove the wrong tags — and a guardrail that misfires is worse than no guardrail.

What it cost vs. what it saved

The build was one Claude Code session, call it $3–4 in tokens and an afternoon I'd have spent on it regardless. It's run hourly since — you can watch it in the log going "No new replies found" at the top of every hour, which is exactly the sound a guardrail should make most of the time. When a reply does land, the next email is dead within 60 minutes instead of whenever I next remembered to check.

Recovered time is the small win: ~20 minutes a day of report-pulling I no longer do, so roughly 2 hours a week. The real win is the one I can't fully price — the warm prospects who don't get robo-mailed mid-conversation anymore, because the check no longer depends on me being awake and remembering.

What an Amazon operator could replicate

This isn't really an email tip. The detect-and-reverse pattern is everywhere in a marketplace business, and almost nobody builds the reverse half:

• Inventory-aware promos. Your Subscribe & Save discount or coupon keeps running while stock quietly drops toward zero — accelerating the stockout that kills your rank. A monitor that detects the inventory floor and pauses the promo is the exact same shape: detect event, reverse in-flight action.
• Ad campaigns past a guardrail. A campaign blows past its ACOS ceiling at 11pm and bleeds budget until your morning check. A detect-and-reverse loop pauses it the hour it crosses the line, not the morning after.
• Buyer-message-aware sequences. Same as my email problem, one level over: a customer who messages you about a problem shouldn't get your automated review-request the next day.

The build skills are modest — an hour with Claude Code, a couple of API calls, a flat-file log. What's rare isn't the engineering. It's the instinct to ask "what action is already in flight when this event happens, and who's reversing it?" Most operators automate the forward motion and leave the reverse to memory and luck. Memory and luck are what robo-mail your best prospects at 6am.

Build the thing that watches your other automations. It's the cheapest insurance you'll ever write — and the one that fires "all clear" every hour is doing its loudest work in silence.