Walking Through an Iterative Refinement Cycle with Claude

An iterative refinement cycle is draft, feedback, revision, repeated across turns instead of expecting a perfect result from a single prompt.

This article follows one realistic task end to end so the pattern is concrete rather than abstract.

Summary

Multi-step delegation means handing Claude a goal and a plan rather than a single narrow instruction, and the iterative refinement cycle is the most common way that delegation actually plays out in practice.

Instead of writing one long, exhaustive prompt and hoping the output lands perfectly, you send a reasonable first attempt, read what comes back, and respond with specific feedback.

Claude revises, you check the revision, and the cycle repeats until the work is good enough to use.

Each turn narrows the gap between what you asked for and what you actually wanted, because feedback grounded in a real draft is far more precise than instructions written before anything exists to react to.

This is not a failure mode to avoid - it is the normal shape of working with Claude on anything that has judgment calls, style preferences, or requirements that are easier to recognize than to specify up front.

Recipe

The core loop, in its simplest form.

State the task and enough context for a first honest attempt - audience, purpose, length, and any hard constraints.
Let Claude produce a full draft rather than an outline or a promise to do it later.
Read the draft and give feedback that names what is wrong and, where you can, why - "the tone is too formal for this audience" beats "make it better."
Ask for a revision that addresses that feedback specifically, and say what to keep unchanged.
Repeat steps 3-4 until the draft meets the bar, then stop - do not keep cycling once it is good enough.

When to reach for this:

The task involves tone, style, structure, or judgment calls that are hard to fully specify in advance.
You expect the first draft to be roughly right but not exactly right.
The output is short enough to read and react to in a minute or two per turn.
You are willing to spend two or three turns to get a better result than one long, over-specified prompt would produce.
You want to preserve context across turns rather than restarting from a blank prompt each time.

Working Example

The task: draft a short status update for a project stakeholder summarizing a delayed launch, without sounding evasive or overly apologetic.

Turn 1 - the initial request.

Prompt: "Write a status update for our stakeholder about the mobile app launch. It's delayed two weeks because of a vendor integration issue. Keep it to one paragraph, professional but not overly formal."

Claude's draft: "I wanted to provide an update regarding the mobile app launch timeline. Due to unforeseen complications with a third-party vendor integration, we have determined that an adjustment to the original schedule is necessary. We anticipate the launch will now take place approximately two weeks later than initially planned. We apologize for any inconvenience this may cause and appreciate your continued patience and understanding as we work to resolve this matter."

Turn 2 - feedback on the draft.

The draft is technically fine, but it reads as evasive - "unforeseen complications," "adjustment to the original schedule," and "any inconvenience this may cause" all soften the message past the point of being useful. It also never names the actual cause or the new date.

Prompt: "This is too vague and apologetic. Name the actual issue (vendor integration problem), give a specific new date instead of 'two weeks later,' and cut the apologetic hedging - one clear sentence of acknowledgment is enough. Keep it one paragraph."

Claude's revision: "The mobile app launch is delayed to March 24th due to an integration issue with our payment vendor that surfaced during final testing. We're working directly with the vendor to resolve it and will confirm the date is holding by March 17th. We know this pushes back plans on your end, and we'll flag immediately if anything changes."

Turn 3 - a second, smaller round of feedback.

Closer, but the draft invented a specific date (March 24th) and a checkpoint date (March 17th) that were not part of the original request - Claude filled in plausible-sounding placeholders rather than leaving them for the requester to supply.

Prompt: "Good structure and tone. But you invented specific dates - I didn't give you any. Replace 'March 24th' with '[new launch date]' and 'March 17th' with '[confirmation date]' as placeholders, and don't invent specifics like that again in this thread."

Claude's revision: "The mobile app launch is delayed to [new launch date] due to an integration issue with our payment vendor that surfaced during final testing. We're working directly with the vendor to resolve it and will confirm the date is holding by [confirmation date]. We know this pushes back plans on your end, and we'll flag immediately if anything changes."

Three turns, each with a narrow and specific correction, produced a usable draft. The first turn established a reasonable starting point; the second turn fixed the vague tone; the third turn caught a fabricated detail the requester would otherwise have had to notice on a final read anyway.

What this demonstrates:

The first draft does not need to be right, only reasonable - refinement is what makes it right.
Feedback that names the specific problem ("too vague," "invented dates") produces a more targeted revision than a vague "make it better."
Each turn built on the previous one instead of restarting, which kept the parts that already worked (the one-paragraph length, the professional tone) intact across revisions.
A later turn caught something the first read missed - fabricated dates - which is exactly what the review step in the cycle is for.
The cycle stopped once the draft was good enough, not once it was perfect - three turns was the right amount of iteration for a one-paragraph status update.

Deep Dive

How It Works

Claude does not have access to your full mental model of "good" on turn one - it only has the prompt. The first draft is a starting point for that model to get transmitted, not a final answer.
Feedback anchored to a concrete draft is more information-dense than an upfront instruction, because you are pointing at a specific sentence or choice rather than describing an abstract preference.
Each turn in the cycle carries forward the conversation's context, so a revision request like "keep the length the same" or "don't invent specifics" applies without having to restate the entire brief.
The cycle converges because each round of feedback removes one category of problem - tone, then specificity, then fabricated detail - rather than trying to fix everything at once.
Diminishing returns set in after a handful of turns; if a fourth or fifth revision is not clearly better than the third, the remaining gap is usually something to fix by hand rather than another prompt.

Element	Purpose	Example from the walkthrough
What's wrong	Names the specific problem, not a general complaint	"too vague and apologetic"
Why it matters	Gives Claude the reasoning, not just the verdict	avoids sounding evasive to the stakeholder
What to change	The concrete fix requested	name the vendor issue, give a real date, cut hedging
What to keep	Prevents the revision from undoing things that already worked	"keep it one paragraph"

Where Checkpoints Fit

Each read-and-feedback step in this cycle is itself a small human review gate - you are approving or correcting the work before it goes further, one draft at a time, rather than reviewing only at the very end.

That is what keeps a multi-turn refinement cycle from becoming multi-step delegation with no oversight: the checkpoints are built into the rhythm of the cycle itself.

Gotchas

Giving feedback that only says "make it better." Claude has to guess what "better" means, and the revision may fix the wrong thing. Fix: name the specific problem, like "too formal" or "missing the actual date," instead of a general complaint.
Rewriting the whole brief instead of giving targeted feedback. Restating the entire original prompt each turn discards the context of what the draft already got right. Fix: respond to the draft itself - point at what to change and what to keep.
Not saying what to keep. Without an explicit "keep the length the same" or "keep this paragraph as-is," a revision can undo something that was already correct while fixing something else. Fix: call out what worked, not just what didn't.
Cycling indefinitely instead of stopping at "good enough." Chasing a perfect result through five or six turns often costs more time than finishing the last mile by hand. Fix: set a rough bar for "usable" before starting, and stop the cycle once a draft clears it.
Skipping the read step and asking for another revision on autopilot. Sending "make another pass" without actually reading the last draft means errors like the fabricated dates in the example can slip through. Fix: treat each turn's read as a real checkpoint, not a formality.
Assuming the first draft was a wasted turn if it needed heavy revision. A rough first draft still does real work by giving you something concrete to react to, which is faster than trying to write the perfect prompt from scratch. Fix: treat the first draft as a starting point, not a graded attempt.

Alternatives

Alternative	Use When	Don't Use When
Iterative refinement (this cycle)	The task has style or judgment calls that are easier to react to than pre-specify	You already know exactly what the final output should look like
One long, fully-specified prompt	The requirements are well-defined, objective, and unlikely to need adjustment	The task involves tone, audience fit, or other judgment calls
Fully delegate with no review until the end	The task is low-stakes and easily reversible if it's wrong	The output goes to a real audience or feeds into further work
Provide an example or template up front	You have a strong reference for what "good" looks like	No good reference exists yet - a first draft is how you'll discover it

FAQs

How is this different from just asking Claude to redo something?

A single redo request is one correction; the refinement cycle is a repeated pattern of read, give specific feedback, and revise, carried across several turns until the result is good enough.

The difference is treating it as a deliberate loop rather than a one-off retry.

How many turns should a typical refinement cycle take?

For a short piece of writing like the status update in the walkthrough, two to three turns is typical.

Longer or more complex tasks may take more, but if a revision stops meaningfully improving on the last one, that is a sign to finish the remaining gap by hand instead of continuing to cycle.

What makes feedback "specific" versus "vague"?

Specific feedback names the exact problem and, ideally, why it matters - "too formal for this audience" or "you invented a date I never gave you."

Vague feedback just asks for improvement in general, like "make it better" or "try again," which gives Claude little to act on.

Should I always let Claude produce a full draft first, or should I outline it myself?

Letting Claude produce a full first draft is usually faster, because it gives you something concrete to react to instead of trying to imagine the result in advance.

An outline-first approach can help for longer or more structurally complex tasks, but for most short deliverables a full draft is the more efficient starting point.

What happened in the third turn of the walkthrough, and why did it matter?

Claude's second draft invented plausible-sounding specific dates that were never provided in the original request.

The third turn caught that and asked for placeholders instead - a reminder that even a well-structured revision needs to be read carefully, not just approved because it looks polished.

Is it a problem if the first draft needs heavy revision?

No - a rough first draft still does useful work by giving you something specific to react to, which tends to be faster than trying to write a single perfect prompt up front.

Heavy revision on turn one is normal, especially for tasks with tone or judgment calls that are hard to specify in advance.

How does this relate to multi-step delegation more broadly?

Multi-step delegation is handing Claude a goal and a plan instead of a single narrow instruction, and the refinement cycle is one common shape that delegation takes when the "plan" is really just draft, review, revise, repeated.

Each read-and-feedback step also functions as a small checkpoint, which keeps the work under review throughout rather than only at the end.

What should I do if a revision is worse than the previous draft?

Say so directly and point back to what the earlier draft got right - it is fine to ask Claude to revert a specific change while keeping other improvements from the later draft.

Treat the conversation as cumulative rather than assuming each new draft has to fully replace the one before it.

Can this cycle be used for tasks longer than a paragraph?

Yes, the same draft-feedback-revision pattern applies to longer documents, though longer drafts are often reviewed and revised in sections rather than all at once, to keep each turn manageable to read and react to.

When should I stop the cycle and finish the work myself?

Once a revision stops producing a meaningful improvement over the previous turn, or the remaining gap is small enough to fix faster by hand than by writing another round of feedback.

Setting a rough bar for "good enough" before you start helps you recognize that point instead of cycling out of habit.

Does giving feedback mid-cycle require restating the whole original request?

No, and doing so is usually counterproductive - Claude retains the context of the conversation, so feedback can be targeted at just the specific change needed, plus a note on what to keep unchanged.

Restating the full brief each turn tends to discard the benefit of the draft that already exists.

What Multi-Step Delegation Looks Like with Claude - the broader pattern this refinement cycle is one instance of
Breaking a Large Task into a Plan Claude Can Execute - planning the steps a refinement cycle might sit inside
Checkpoints and Human Review Gates in a Delegated Workflow - the review step that each refinement turn is a small instance of
When to Delegate Fully vs Keep Claude in a Tight Loop - deciding whether a tight iterative loop like this one is the right call
Multi-Step Delegation & Orchestration Best Practices - section-wide practices this cycle follows

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.