Stopping Revision Loops in AI Workflows
A reviewer could keep sending a draft back for changes. I put the revision count and next status in application code so rejection had a stopping point.
I tested a pipeline where one model gathered research, another drafted, and a third reviewed. A rejection sent the draft back for revision, and vague feedback could keep that loop running.
Keep the draft and its status together
The job state held the brief, research items, draft, review result, and attempt count. Each step could update that record instead of leaving the controller to reconstruct progress from a conversation.
The schema checked the shape of that state. Source accuracy and whether a review made sense still required separate checks; an approval flag was the reviewer's answer, not proof that the draft was correct.
Put a count on revision
Once a review returned, the router used three branches. Approval set the approved status. Rejection below the configured limit incremented the count and requested a revision. Rejection at the limit set manual review and recorded why it had stopped.
approved → approved status
rejected below limit → revision required
rejected at limit → manual review
Manual review was a pause for a person to resolve, not automatic approval. This router handled a returned review; malformed output, provider errors, and calls that never returned needed their own validation and timeout paths.
Record why the status changed
The transition record included the job ID, previous and next status, agent name, token counts, duration, cost estimate, validation result, and failure reason. Those fields let an emitted record explain a rejected or stalled step without storing the full prompt and response.
Have a similar project?
Talk to Me