I like AI automation a lot, but I do not trust giant prompts that try to carry the whole world into every cron run. They start impressive, then slowly turn into a junk drawer. Old rules stick around, topic coverage drifts, and the writer spends too much effort re-deciding basics that should already be structured.
For recurring jobs, I have had better results with a tiny context builder in front of the writer. One script gathers the current account, recent history, constraints, and a few selected inputs. The writer then works from that compact payload instead of a monster prompt. It is less romantic, maybe, but way more useful.
Why giant prompts age badly in cron jobs
A scheduled workflow lives longer than the assumptions inside it. That is where trouble starts.
At first, a large prompt feels flexible. You can stuff in policies, examples, topic lists, and fallback rules. A month later, nobody is quite sure which parts still matter. Some instructions conflict quietly. Others are technically correct but stale. The run still "works," yet the output gets a bit mushy and a bit repetetive.
That is why I prefer small, explicit context objects. They force the system to say what is true right now:
- which account is active
- which topics are in bounds
- which internal links are allowed
- which constraints are hard requirements
- which recent posts should be avoided
This is basically the same lesson behind clear state boundaries in automation and stable backend rules for repeated jobs. Reliable systems do better when decision inputs are named and scoped, not smeared across a big wall of text.
What a context builder should produce
The builder does not need to be fancy. In fact, simpler is usualy better. I want one JSON object with just enough information to write well.
For a content job, that often means:
- the selected account and language
- recent publishing history
- topic keywords that fit the account
- platform constraints like title length or tag count
- preselected internal links
- optional SEO terms that can appear naturally
Notice what is missing: the full archive, every policy ever written, and a huge stack of examples. If the writer needs all of that every single time, the system design is already telling you something.
Here is the mental model I use: the builder decides the playground, the writer plays inside it. That split removes a lot of weirdness from scheduled runs, and it also makes failures easier to inspect later.
A simple build then write pattern
The pattern is boring on purpose:
type WriterContext = {
account: { username: string; language: string; topics: string[] };
constraints: { titleMax: number; backlinkCount: number };
internalLinks: Array<{ url: string; anchor: string }>;
recentHistory: Array<{ title: string; publishedAt: string }>;
primaryKeywords: string[];
typoKeywords: string[];
};
const context = await buildWriterContext();
const plan = planArticle(context);
const article = writeArticle(plan);
await publish(article);
What matters is not the TypeScript. What matters is the order. Build context first. Freeze the plan. Write once. Publish from the approved artifact. If the publish step fails, do not sneak in a second rewrite and hope no one notices. That path gets messy fast, and it makes debugging kind of annoying tbh.
I also like this pattern because it keeps the writer honest. When the source payload is small, you can see the actual levers behind the output. The article is not "smart" because the prompt is enormous. It is useful because the inputs are shaped with care.
Where temporary email workflows fit
This is not only for publishing systems. The same pattern shows up in signup tests, inbox checks, and preview environments where a temporary email flow is part of the job.
Say your automation needs a tempmail.so inbox for verification. The builder can decide which inbox rule, timeout, and environment label apply to this run. The writer or executor should not rediscover that from prose. The same goes for noisy search terms your team may see in logs, like dummy e mail or temp mailid. Those strings can be relevant context, but they should enter the run as explicit fields, not as forgotten fragments hidden inside a giant prompt.
That distinction sounds small, but it changes how teams work. People stop treating automation like a mysterious black box and start treating it like a pipeline with named inputs. Less magic, more leverage. I think that is a prety good trade.
Q&A
Does this make prompts too rigid?
Not really. It makes runtime facts explicit. You can still keep a stable writing guide outside the context builder. The trick is not to mix evergreen guidance with per-run decisions.
How small should the context be?
Small enough that a human can skim it in under a minute. If the JSON feels like a novel, trim it. If important choices are missing, add only those.
Should the builder write the article too?
I would avoid that. Once one step both gathers inputs and writes output, it becomes harder to test each part cleanly. Separate roles are a little less flashy, but much easier to trust after weeks of cron runs.
Top comments (0)