AT-201a · Module 3
Iterative Refinement Loops
4 min read
The create-review-revise cycle is the workhorse pattern of production agent teams. The worker creates a first draft. The critic reviews it and returns scored feedback. The worker revises based on the feedback. The critic reviews the revision. This cycle repeats until the stopping condition is met. Simple in concept. Nuanced in execution.
The nuance is in how the revision prompt is constructed. A naive approach sends the critic's full feedback to the worker and says "fix these issues." The problem: the worker now has its original draft, its original context, and the full critique all competing for context window space. If the critique is detailed — and it should be — the worker's context is significantly more crowded in round two than it was in round one. Quality can actually degrade in revision if the context management is poor.
The solution is structured revision prompts. Instead of dumping the full critique, the coordinator extracts the specific items to fix — "Section 3 revenue figure should be 28%, not 40%. Add Company C, D, and E to the comparison table. Include three additional source URLs" — and sends only those action items to the worker. The worker receives its original draft as a file reference, a focused list of corrections, and nothing else. The context stays clean. The revision stays focused.
After the revision, the critic receives only the new version — not the original draft, not the previous critique, not the revision instructions. Fresh eyes on fresh content. The critic evaluates the revision on the same dimensions with the same scoring system and returns new scores. If scores improved and all dimensions pass the threshold, the cycle ends. If scores improved but the threshold is not met, another round begins. If scores did not improve or regressed, the coordinator intervenes — something is structurally wrong and more iteration will not fix it.
The refinement loop also generates valuable data over time. Track the scores across rounds for every deliverable your team produces. After 20 deliverables, patterns emerge. "Our first drafts consistently score low on completeness but high on clarity." That pattern tells you the research stage is not feeding enough data to the drafting stage — fix the pipeline, not the writer. "Round two consistently fixes accuracy issues but introduces formatting problems." That tells you the revision prompt needs to include formatting constraints.
These patterns are operational intelligence. They reveal the systemic weaknesses in your pipeline, not just the per-deliverable issues. A team that tracks refinement loop data improves its architecture over time. A team that treats each deliverable as an isolated event repeats the same structural mistakes indefinitely.