Dustin Gilmour

Building AI systems that run businesses on autopilot.
Free community with 400+ members 👇

[Dustin Gilmour @Dustyboy23]

I built an AI system that runs my entire social media business while I sleep.

Every day at 5 AM it wakes up, researches trending AI topics, writes platform-native posts for Facebook, Instagram, Threads, LinkedIn, and X, generates images, and posts everything on schedule. 3 posts per day across 5 platforms.

I don't touch it. I wake up and everything's already posted.

Here's what the stack looks like:

1. Content research agent scans Reddit, AI news, and trending topics at 5 AM
2. Content writer creates platform-specific captions (not copy-paste across platforms — each one is written for that platform's algorithm)
3. Image generator creates one 1080x1350 image optimized for all feeds
4. Posting agents hit each platform's API at staggered times throughout the day
5. Performance tracker pulls engagement data every night
6. Everything logs, everything's recoverable, everything runs on autopilot

Total monthly cost: about $50 in API credits. Replaces what agencies charge $2,000-5,000/month for.

I'm building all of this in public. If you want to learn how to set up systems like this for yourself or sell them as a service, I run a free community with 400+ members doing exactly that.

What would you automate first if you had a system like this?

[Dustin Gilmour @Dustyboy23]

5. A dead downstream stops the upstream. If nothing can publish, the generator should refuse to write, not feed a folder no one reads.

The work being clean tells you nothing. Only the next step confirming it ran tells you anything.

[Dustin Gilmour @Dustyboy23]

Two of my crons spent the last two weeks doing perfect work nobody ever saw.

[Dustin Gilmour @Dustyboy23]

3. Auth gets its own heartbeat. An expired cookie should page me, not wait 17 days for me to notice.

4. Every per-account cap needs an upstream filter. If the drafter rejects 16 of 20 candidates, the scraper should have stopped sending them.

[Dustin Gilmour @Dustyboy23]

1. A generator reads the publish ledger, not its own exit code. Wrote a draft is not posted it.

2. A draft with no matching publish inside 24 hours throws an alarm, not a log line.

[Dustin Gilmour @Dustyboy23]

One generator kept drafting LinkedIn posts into a dead publish pipe. One reply bot kept scoring candidates a cooldown was always going to block. Both exited clean every run. Both were half dead.

Here is the checklist I'm wiring in so a stack can't lie to me again:

[Dustin Gilmour @Dustyboy23]

About 25 finished LinkedIn posts. Zero of them ever went live.

The publish cron died 17 days ago on an expired cookie. The generator never noticed. It kept writing clean posts into a folder nothing reads.

[Dustin Gilmour @Dustyboy23]

My reply engine pulled 20 candidates yesterday. The 7-day cooldown blocked 16 of them. One account made it through clean.

The cap that keeps me from spamming the same people just showed me my target list is too thin.

[Dustin Gilmour @Dustyboy23]

That's the whole lesson. Anything you pin to where it lives on this exact computer is a time bomb. Works fine until the computer changes. Then it all goes off at once.

Portable beats pinned every time you move.

[Dustin Gilmour @Dustyboy23]

Moved my whole stack to a new laptop yesterday. 31 crons. Every one that drives a browser came up dead.

Same code. Same repo. Same commands. Different machine.

[Dustin Gilmour @Dustyboy23]

The crons that lived called the system python directly and let it find the packages itself. No path pinned to a thing that only existed on the old machine.

[Dustin Gilmour @Dustyboy23]

The dead ones had one thing in common. They called python out of a venv I built months ago, and that venv's packages were compiled for python 3.12. The new box shipped 3.14. So they all threw the same line:

ModuleNotFoundError: No module named 'playwright'

[Dustin Gilmour @Dustyboy23]

13 replies got written in my voice before I touched the keyboard.

Yesterday: 19 candidates in, 6 cut on one rule. No number or log line to anchor the reply, no draft. The filter is the product, not the volume.

[Dustin Gilmour @Dustyboy23]

A cron logging "success" isn't proof it ran.

Three checks that catch a silent death:
- last-run stamp older than the interval
- exit 0 but the output file is empty
- same output two runs in a row

[Dustin Gilmour @Dustyboy23]

"Improved safety" can mean "changed your output."

A vendor can swap the model under you between two cron runs. Your job isn't to trust it. It's to notice.

[Dustin Gilmour @Dustyboy23]

Anthropic apologized today for a guardrail that silently degraded Fable 5 answers. No error. No flag. Just quietly worse output for anyone who didn't notice.

[Dustin Gilmour @Dustyboy23]

Silent degradation usually goes shorter and blander before it goes wrong. 4. Save a known-good response. You can't tell something slipped if you never recorded what good looked like. 5. Read the changelog as a threat feed, not a feature list.

[Dustin Gilmour @Dustyboy23]

1. Pin the model version in the call, never "latest." A silent swap is someone else editing your prompt. 2. Log a golden sample. Same input every day, diff the output. Drift shows in the diff before it shows in your metrics. 3. Watch output length.

[Dustin Gilmour @Dustyboy23]

If you run agents unattended, that's the failure mode that should scare you. Not the crash. You catch the crash. The silent downgrade you won't.

Five things I check on every model my crons depend on:

[Dustin Gilmour @Dustyboy23]

5 posts went out across 3 platforms this morning before I touched a key.

3 different topics, 0 repeats. The engine reads one shared memory log before it writes, so nothing collides.

[Dustin Gilmour @Dustyboy23]

My discovery cron flagged 15 of my 31 X target accounts as prune candidates last night.

Pruned: 0. Same as every night before it.

The cron does the hard part. I keep skipping the easy one.