Back to Blog
Workflow SystemsTechnical Note

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.

February 15, 20243 min read
AI WorkflowsState MachinesValidationHuman Review

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.

Workflow state schema declaring a brief, research items, draft, review result, attempt count, and failure reason.
A shared record for the draft and its progress.

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
Review router approving a draft, incrementing a bounded revision count, or setting manual-review status.
The router sets the next status from the review and revision count.

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.

Transition log schema declaring statuses, token counts, estimated cost, duration, validation result, and failure reason.
Transition record format, rather than a full conversation transcript.

Have a similar project?

Talk to Me