Fixing automated generation bottlenecks requires isolating retry counts.
Quick solution:
const LIMITS = { buildRetries: 1, reviewRetries: 1 };
Configure separate attempt counters for builder-side schema checks and reviewer-side editorial feedback so that a formatting fix does not starve your qualitative review loop. Developers can reference the Cloudflare Workflows sleeping and retrying guide to manage state across asynchronous steps. A shared retry counter in an automated generation workflow can consume its only repair turn on early schema formatting, leaving no room for qualitative reviewer feedback. When a builder encounters structure issues during its first generation, a second attempt might pass deterministic checks only for a subsequent reviewer to request deeper source analysis or a comparison table. If both phases share a single pool of retries, the workflow runs out of turns and fails before publication.
Isolating Validation and Reviewer Repair Budgets
In structured output generation models such as those detailed in the Google Gemini structured output documentation, schemas enforce data types, but application logic still validates semantic constraints. If a builder output fails deterministic schema or field checks, it needs an immediate local correction. Separating this initial validation budget from the subsequent editorial review phase ensures that an early syntax repair never steals the turn reserved for qualitative critique.
When a workflow relies on sleeping and retrying primitives, state management becomes straightforward. Each state step increments its own dedicated counter. If the builder fails validation once, it consumes the validation repair budget. Once it passes, it hands off to the reviewer without touching the review repair pool.
Bounding Total Builder and Reviewer Call Caps
To prevent infinite loops and runaway API costs, you must define strict upper bounds on total model invocations. A runaway generation loop can drain rate limits and incur unexpected expenses if left unbounded.
By capping builder calls at three and reviewer calls at two, the orchestration layer guarantees a hard stop. If the builder exhausts its single validation retry, the workflow fails fast before ever reaching the reviewer. If the builder passes validation but the reviewer rejects the draft twice, the system stops and preserves the artifact for manual inspection.
Preserving Rejected Candidates for Review
When a candidate fails the final review tier, the workflow must not delete the artifact or silently drop it. Instead, it should store the failed output alongside the reviewer diagnostics in persistent storage, such as a local database or key-value store, while keeping the publication flag set to false.
This behavior gives engineers visibility into why the model failed without risking unverified content leaking into production. You can read more about how to make AI reviewer feedback actionable when analyzing these stored failure logs.
Verification and Execution Checklist
- Run a test where the builder fails its first validation check, repairs successfully, passes the reviewer on the first try, and results in a published article with expected success.
- Run a test where the builder passes validation immediately, but the reviewer requests changes twice, exhausting the review repair budget and correctly halting execution.
- Run a test where the builder exhausts its validation retries on attempt two, ensuring the reviewer step is skipped entirely and the run terminates with a validation error status.
Conclusion
Isolating validation checks from editorial review loops stops early schema errors from starving your quality gates. By defining explicit caps for each phase and preserving rejected outputs for analysis, you maintain a predictable and reliable generation pipeline.
