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
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?