If you run a scheduled writer across multiple DEV accounts, the hard part is usually not generating text. The hard part is choosing a topic that still fits the account, does not repeat last week, and does not feel like the system just shuffled the same nouns again.
I learned this the annoying way. Early versions of a cron writer looked productive on paper, but the topic picker kept leaning toward whatever was easiest to satisfy. That meant decent drafts, yet not much variety. After a few days the feed started to feel same-ish, and that is where trust begins to slip a bit.
Why recurring writers drift into repetitive topics
A recurring writer sees the world through constraints:
- recent post history
- account topics
- required keywords
- internal links
- publish-safe formatting
If you do not explicitly score for novelty, the system drifts toward convenience. It grabs the closest familiar angle, swaps a few phrases, and calls it fresh. The result is not always bad, but it often lands in that awkward middle where the article is useful enough to publish and forgettable enough that nobody realy remembers it.
For a builder-style account, I think the better question is simple: what useful thing have we not explained clearly yet?
That is why I prefer topic gaps over pure randomization. Random prompts create variety, sure, but they also create off-brand detours. Topic gaps keep the writing closer to the account's real lane while still pushing it into new ground.
Score for freshness before you score for convenience
My rule now is: score freshness first, then fit, then execution ease.
Freshness means checking the last several published titles and keywords for overlap. If the account just posted about retries, the next draft should probably not be another retries post with slightly different wording. Fit means the topic still belongs to the chosen voice and subject area. Execution ease only comes after those two, because the easiest article to generate is often the one you should skip.
This mindset pairs well with approval files for safer automation runs. Once the planner commits to one title and one outline, the rest of the workflow stops wandering. The article gets written once, and the publisher simply executes.
It also helps to think in clusters instead of isolated keywords. A phrase like fake email address might appear in the context, but the article does not need to become an email post every single time. Sometimes the better use is indirect: write about the workflow that decides when a keyword belongs, when it should be background only, and when it should be left out. That small distinction made the system feel much less robotic in practice.
Build a small planning contract around the topic choice
I do not want the publisher deciding editorial direction, and I do not want the writer rethinking itself after the plan is set. So the planner writes a compact contract:
- selected account
- language
- title
- tags
- primary and semantic keywords
- internal links
- outline
That gives you one frozen decision point before any browser automation starts. If the final post feels off, you can inspect the plan and see whether the mistake happened during topic selection or during article writing.
This is where immutable retry records become unexpectedly important. Without them, retries can blur together and make it hard to tell which exact plan created which post. With them, each run stays inspectable, which is boring in the best way.
What I keep in the selection context
The context does not need to be huge. In fact, smaller is often better. Mine usually includes:
- account summary and topics
- recent titles, tags, and primary keywords
- allowed internal links for this run
- hard constraints like backlink count or language
That is enough to make a grounded choice without creating a monster prompt. A giant context dump can make the planner noisier, not smarter. It starts reacting to trivia instead of the central editorial question.
One useful trick is writing down why the chosen title is different from the last few posts in one sentence before drafting. If you cannot explain the difference plainly, the angle is probably too close. This catches a lot of near-duplicates before they become published clutter.
I also keep a few intentionally human edges in the final draft. Not sloppy ones, just enough to avoid the sanded-down machine feel. A tiny slip like writing tempail in a non-critical sentence is fine if the rest stays clear and credible. Overdoing that, though, looks weird fast.
Quick Q&A
How many recent posts should the planner compare?
Usually the last 10 to 20 is enough for a daily or multi-daily writer. You want enough history to catch repetition, but not so much that old topics become permanently banned.
Should every account have a different scoring model?
Not necessarily. The model can stay mostly shared. What should differ is the account profile, preferred topics, and writing style that shape the final decision.
Is randomness still useful?
Yes, but as a tie-breaker. If two angles are both fresh and on-brand, a little randomness is healthy. It should not be the main steering wheel, imo.
The biggest improvement was not better prose generation. It was forcing the system to prove that today's topic deserved to exist. Once the planner has to show a real gap, the whole cron writer becomes calmer, sharper, and a lot easier to keep running.
Top comments (0)