B\*tchwork my AI Did for Me - Part 37: My AI Posts My Substack Notes 10 Times a Day Without Repeating Itself
My automation was supposed to post ten fresh Substack notes a day and move on. Instead it kept recycling the same text. I handed the fix to my AI and told it to never let that happen again.
The system was supposed to be invisible.
Ten posts a day. Every day. Scheduled across the morning, the afternoon, and the evening. A different note each time. No repeats.
That is the promise of full automation. You set it up once, you walk away, and it runs.
Except one morning I checked the queue and saw it.
The same note. Posted twice. Pulled from the backlog like nothing happened. Like the system had no memory at all.
The problem was real. The automation was looping back to notes it had already used. The lane it pulled from was not checking what had already been sent. It was just grabbing whatever was next in the list, loading it up, and posting it again.
For a content brand that runs on trust, that is embarrassing. A repeat post tells your audience one of two things. Either you are not paying attention, or your tools are broken. Neither is a good look.
So I stopped running the automation and handed the problem to my AI.
I did not want a patch. I wanted a system that could never do this again.
Here is what I told it to build.
What the old system did wrong
The old flow pulled notes from a queue, posted them, and marked them done.
The problem was the "marked them done" part. The system only tracked whether a note had been sent through the posting step. It did not check whether that note was still sitting in the recent history window. It did not check whether all the social channels had confirmed the post before it moved on. It did not rotate away from notes that had been used too recently.
So when the queue ran low and the backlog filled in, the same notes came back around.
The system also had a stale-radar problem. There is a freshness check built into the lane that is supposed to flag old content. But when that check ran on a thin backlog, it was treating old notes as fresh because there was nothing newer to compare them against. The fail state was not closed. It pretended stale content was fine.
That is how a ten-posts-a-day system becomes a greatest-hits reel of your old content.
What I handed to my AI
I gave my AI the two main files that run the note system.
The refill file controls how new notes get pulled into the lane. The autopost file controls how notes get picked, scheduled, and confirmed across channels.
I told my AI to read both files and then answer one question first: where does this system trust that a note has not been used when it has not actually checked?
It found four gaps.
The lane was not checking Posted history before adding a note to the active queue. The autopost was marking a note as Posted after the first channel confirmed, before the other channels had finished. The stale-radar was allowed to pass when it should have blocked. And there was no rotation rule that forced the system to skip a note that had been used recently, even if it had technically aged out of the immediate dedup window.
I told my AI to close all four gaps and write tests for each one.
Receipts I can prove
The fix lives in two files in my ATHENA repo.
content-system/substack/lotw-lane-refill.mjs — this is the file that controls which notes get pulled into the active lane. The updated version now checks the Posted history before a note can enter the queue. If a note appears in recent Posted records, it does not get loaded. It waits.
content-system/substack/device/substack-autopost.mjs — this is the file that runs the actual posting. The updated version does not mark a note as Posted until every channel it was supposed to hit has confirmed. If one channel fails or does not respond, the note stays in a pending state instead of being written off as done.
Both files have test suites: lotw-lane-refill.test.mjs and substack-autopost.test.mjs. The tests cover the dedupe check, the all-channel-settle requirement, the stale-radar fail-closed rule, and the rotation logic that forces the system to skip recently-used notes even when the backlog is thin.
The tests are local. They run against the code. They are not proof that every post landed clean on every network. What they prove is that the logic now handles all four gaps that caused the repeat problem.
I am not claiming a full clean day of posts is already logged. The system was repaired on 2026-07-27. What I have is the code, the tests, and the guardrails. The live run is still ahead of me.
Behind this paywall
Paid readers get:
The exact prompt I gave my AI to find where the system was trusting without checking.
The four-step fix broken down in plain language you can follow even if you have never read code.
The checklist I now use before turning any autopost system live.
The parts my AI could not decide on its own and why those stayed with me.
A copy-this prompt you can use if your own automation is repeating itself.
What paid subscribers get every week
Paid subscribers do not only get this one automation repair. You also get:
Real work I handed to my AI inside my actual business.
The prompts I used, written so you can copy them.
The receipts that prove what worked.
The problems that slowed the job down.
The safety checks that kept AI from making a risky call on its own.
Simple playbooks you can use in your own business.
Subscribe and the rest of this article opens right away. You get the full repair, the prompts, the checklist, and the copy-this recap now.
The full walkthrough is below the paywall.
Click the button, subscribe, and the locked section below opens right away. You get this article now.
