I let a cron expire 69 of my own drafts. Best call this month.
Last week I posted here about driving my AI content system's defect count from 121 to 0. The follow-up is less glamorous: I gave the system permission to throw my own work away, and it threw away 69 pieces on day one.
What happened. My marketing runs on an agent pipeline that drafts content and stages it for approval. The failure mode was never bad drafts. It was good-enough drafts nobody acted on. Anything that needed my approval sat in a queue, and the queue only grew. By mid-July I had briefs that had been waiting 18 days for a story detail only I could supply. They were never going to ship. They were also never going to leave.
So on July 19 I added a staleness rule: anything sitting in a human-approval state for 21 days auto-expires, daily at 09:00 UTC, logged, reversible with a one-line status flip. Nothing is deleted. First sweep: 69 items expired. The sweep two days later caught 7 more. This week I cleared the remaining human queue in one sitting (5 approved, 4 killed) because for the first time it was short enough to read.
What I learned. A backlog is not inventory, it is anesthesia. Those 69 items made the system look productive while hiding the real constraint: my attention was the bottleneck, and every stale draft was a small claim against it. The rule did not cost me content. It cost me the illusion of content.
What I am trying next: moving the whole pipeline from approve-to-publish to publish-with-veto for anything that passes the automated voice and fact gates, and keeping my approval for the categories that need a human (first contact with a real person, money, anything claiming a new fact about my life). The queue should hold decisions, not deposits.
The longer write-up of the whole system is here: chadtdyar.com/blog/ai-in-production
The smart part here is the reversible expiry. Before moving everything to publish-with-veto, I'd tag each expired item with why it stalled, like missing founder input, a weak angle, a duplicate topic, or plain neglect. After a few passes, those tags would show which approval steps you can cut and which categories still need a person. A regret rate on published items, plus a stall-reason rate on expired ones, would give you both sides of the system.
This is a good product instinct applied to your own workflow rather than a product, and it generalizes: a backlog that only grows is a pile of deferred decisions, and expiring it is you finally making the decision "no." I try to build the same thing into products — a good default quietly removes a decision instead of adding a setting — and it's striking how rarely we grant ourselves the same courtesy in our own tooling.
One thing I'd watch: 21 days is a fine rule right up until the one brief you actually needed expires because a single fact was blocked on you. Might be worth a lightweight "about to expire" nudge for anything you've touched at least once, so genuine one-offs don't get swept out with the good-enough-but-abandoned pile.
The part that stands out is not the 69 expired drafts, but that the queue became short enough to make decisions again. The queue length itself may have been reducing the quality of your judgment.
For publish-with-veto, I’d probably track a “regret rate”: how often an auto-published item gets edited, withdrawn, or corrected within a week. That seems more useful than output volume for deciding which categories can safely leave the approval queue.
Are you planning any post-publish sampling or rollback window before expanding it?
"Good-enough drafts nobody acted on" is the exact failure mode that kills more indie projects than bad ideas ever do. The queue isn't a backlog — it's a graveyard with a to-do list UI.
I noticed the same pattern with my KDP books. The first batch of 10 took 3 weeks because I kept tweaking covers and keywords. Then I set a rule: if I hadn't shipped a book within 48 hours of the PDF being ready, I auto-published it as-is. The ones I shipped fast weren't worse — they were just done. And a published book that could be improved later was infinitely better than a draft that would never ship.
The cron didn't delete your work. It deleted your procrastination. Curious: did you feel relief or anxiety when you saw 69 killed?
"backlog is not inventory, it is anesthesia" is the sharpest bit. one thing worth naming though: the cron didn't kill 69 drafts, it revealed that approval was never going to happen. worth asking why not.
if it's time-scarcity, publish-with-veto scales cleanly. if it's per-item quality doubt, veto doesn't fix that, you just publish the doubt instead of storing it. those are different pipeline bugs. what's the actual reason drafts sit past 21 days when the generator's improved?
Letting drafts die is a stronger design choice than endlessly improving the generator. Once creation is nearly free, unfinished inventory becomes the real cost: review time, decision fatigue, and a backlog that makes every new idea harder to judge.
The interesting next step is whether that 69% expiry rate feeds back into the pipeline. Are you tracking why drafts expire, weak premise, bad timing, insufficient evidence, or simply no distribution slot, so the system learns to create fewer low-priority drafts rather than merely deleting them faster?
The staleness rule is the right shape. The part I would harden is the condition it fires on.
I ship a Mac app that syncs through the user's own iCloud, and I have a sweep with a similar job: find records nothing references anymore and clean them up. Written naively that is a time-based rule, and in production it is unsafe, because it can run before sync has finished pulling everything down. In that window a record that exists on another device is indistinguishable from an orphan. So the sweep is gated on "have I actually seen the full state yet" and stays non-destructive whenever the answer is no. I did lose data once to the same family of bug, a device acting on an incomplete picture, and what made it expensive was that it looked like success from the inside.
Your 21 days is standing in for a fact you would rather measure directly. If a brief is waiting on a story detail only you can supply, what kills it is that you have decided not to supply it, not that a timer ran out. Worth asking what the direct signal is, because time-based rules fail quietly and look productive while they do it.
The reversible-by-status-flip part is what makes this safe to be wrong about, and I would not trade that away when you move to publish-with-veto.
The interesting shift is that the bottleneck moved from content generation to human judgment allocation.
How are you deciding which categories deserve human approval permanently, versus trusting the system enough to let automation own the decision?