Iterative Refinement

When a model receives a prompt with no prior conversation history, it must satisfy the broadest reasonable interpretation of your request. Asking for 'a marketing analysis' could mean a competitive landscape review, a campaign performance assessment, or a market sizing exercise. The model hedges by producing something moderately relevant to all interpretations — which means it is deeply relevant to none of them.

This breadth-over-depth behaviour is rational from the model's perspective. It has no way to know which interpretation you intend, so it optimises for the response most likely to be acceptable across all possibilities. The result is generic but safe — unlikely to be wildly wrong but equally unlikely to be precisely what you need.

Your follow-up messages function as a progressive narrowing of the solution space. Each correction — demonstrated practically in this workflow teardown — 'focus more on pricing strategy', 'use data from the UK market specifically', 'the audience is the board, not the marketing team' — eliminates interpretations and steers the model toward the specific output you need. The fourth response benefits from three rounds of accumulated context that the first response could never have.

This is why conversation planning and iterative refinement are complementary skills. Planning front-loads context to make the first response better; refinement improves subsequent responses based on what the first attempt reveals about the gap between the model's interpretation and your actual need.

The most effective feedback is specific and directional: 'Expand the section on cost analysis and reduce the background context' is more useful than 'make it better'. The model needs to know what to change, in which direction — a principle shared with prompt debugging, and ideally what the current output gets right so it preserves those elements while modifying the rest.

Pointing to specific gaps is more effective than requesting general improvements. 'You haven't addressed what happens when the API fails' targets a concrete missing element. 'Be more thorough' gives the model no actionable direction — it may add length without adding substance, padding the response with generic content rather than addressing your actual concern.

Sharing your reaction to the output is also valuable feedback. 'This reads as too academic for our sales team' tells the model about the audience mismatch. 'The recommendations are too vague to act on' tells it about the specificity level required. This human-judgment feedback is precisely the information the model could not infer from the original prompt — it needs to see your reaction to calibrate its next attempt.

Negative feedback (what to remove or change) often drives larger improvements than positive feedback (what to add). Telling the model to 'stop summarising background I already know and jump to the novel insights' produces a dramatically different response structure. Negative constraints act as clear boundaries that reshape the entire output, not just one section.

If the model's fundamental approach or framing is wrong — not just the details but the entire angle — refinement is less efficient than restarting with a better initial prompt. Refinement works best when the model is heading in the right direction but needs course corrections on specifics. It works poorly when the model has committed to a direction that fundamentally does not serve your needs.

Very long conversations also hit diminishing returns. After many rounds of refinement, the conversation history fills the context window with earlier, less relevant versions of the output. The model's attention is split between your latest feedback and the accumulated history of prior attempts. Starting fresh with a prompt that incorporates everything you learned — the correct framing, the specific requirements, the desired format — often produces a better result in one message than further refinement of a long thread.

A practical heuristic: if your last three feedback messages have all been redirections rather than refinements — changing the approach rather than adjusting details — start over. You now know enough about what you want to write a prompt that gets it right from the first response. The failed conversation was not wasted; it was an exploration that clarified your requirements.

When restarting, explicitly include the lessons from the previous conversation. 'In a previous attempt, the analysis focused too heavily on market size and not enough on competitive dynamics. For this version, I need competitive dynamics to be the primary lens' gives the model the benefit of your refinement experience without the attention cost of carrying the full prior conversation.

The most effective team approach is to share not just prompts but the full refinement chain — initial prompt, first response, feedback that improved it, and final output. This teaches team members which types of feedback drive the biggest improvements, creating a shared vocabulary for steering AI output that goes beyond individual prompt engineering skill.

Prompt libraries gain additional value when they include refinement notes. A prompt tagged with 'first response tends to be too formal — follow up with "match the tone of our engineering blog, not a white paper"' is more useful than the prompt alone, because it anticipates and pre-solves a known refinement need. Over time, these notes accumulate into a team knowledge base about how the model interprets different types of requests.

Feedback loop design formalises this process. Teams that track which feedback patterns produce the largest quality improvements can systematically improve their prompts to reduce the need for refinement. If every analysis prompt requires a follow-up asking for more specific recommendations, that specificity instruction should be incorporated into the base prompt. The goal is to make the first response good enough that refinement is enhancement, not correction.

The most common mistake is vague positive reinforcement followed by a vague request for more. Saying 'That's great, can you add more detail?' gives the model no signal about which parts were great or what kind of detail is missing. The model may expand sections that were already sufficient while leaving the actual gaps untouched. Effective refinement always specifies what to expand, what to keep, and what to cut.

Another frequent error is feedback that contradicts earlier feedback without acknowledging the contradiction. If round two asked for a formal tone and round four asks for a conversational tone, the model must reconcile competing instructions from the same conversation. Explicitly noting 'I changed my mind about tone — ignore the earlier instruction about formality and make this conversational throughout' prevents the model from producing awkward hybrid prose that tries to satisfy both directives.

Micro-refinement — making one tiny adjustment per message over many rounds — is less efficient than batching several corrections into a single message. Each round of refinement regenerates the full output, and trivial changes do not justify the context cost. Collecting three or four adjustments and delivering them together produces the same result in fewer exchanges, preserving context window space for substantive conversation.