The Reflection Pattern: Teaching AI
to Review Its Own Work

In Part 1, we covered what Agentic AI is and why it’s more powerful than simply prompting an AI and getting a one-shot answer. If you missed it, start there.

In this article, we go deep on the first of the four core agentic design patterns: Reflection.

You already do this. You just didn’t call it that.

Think about the last time you wrote something important — an email, a message, a document.

You probably didn’t send the first draft.

You wrote it, read it back, noticed something off — a typo, an unclear sentence, a tone that felt wrong — and fixed it before hitting send.

That process of writing → reviewing → improving is so natural that we don’t even think about it. It’s just good practice.

The Reflection Pattern brings that same process to AI.

Instead of asking an AI to generate an answer in one go and being done with it, you ask it to generate a first draft, then reflect on that draft and produce a better second version.

Simple idea. Surprisingly powerful results.

How it actually works

Here’s the basic flow:

1. You give the AI a task
2. The AI generates a first draft (V1)
3. You pass that draft back to the AI — same model or a different one — with a prompt that says: “Review this. Find problems. Improve it.”
4. The AI produces a better second draft (V2)
5. Repeat if needed

That’s it. No complicated engineering. Just a second prompt that tells the AI to look critically at its own output.

It works for code too — and this is where it gets interesting

The reflection pattern really shines when it comes to writing code.

Here’s the typical flow without reflection: you ask an AI to write a Python function, it generates something that looks reasonable, you run it, and it crashes with a syntax error you have to debug yourself.

With reflection, you add one extra step: you run the code, capture whatever error message comes out, and feed both the code and the error back to the AI.

Now instead of saying “here’s some code, check it”, you’re saying “here’s the code you wrote, here’s the exact error it threw when I ran it — fix it.”

That error message is external feedback — new information from outside the AI’s own reasoning. And this is the key insight of the whole module:

Reflection is significantly more powerful when it has access to new external information, not just its own output to look at.

Without external feedback, the AI is just re-reading what it already wrote. It might catch something, but it’s working from the same information it had before.

With external feedback — an error log, test results, a failed execution — it has new evidence to reason from. That’s when reflection really delivers.

How to write a good reflection prompt

This is more practical than it sounds. A few principles that make reflection prompts work better:

Be explicit that you want a review. Don’t just re-ask the same question. Tell the AI its job is to critique and improve, not generate fresh.

Give it specific criteria. “Make this better” is too vague. “Check whether the tone is professional, verify all dates are accurate, and confirm the instructions are in the right order” gives the AI something concrete to evaluate against.

Give it external information when you can. Error messages, test outputs, failed results, user feedback — all of these dramatically sharpen the reflection.

Here’s an example reflection prompt for reviewing domain names:

“Review the domain names you suggested. Check if each name is easy to pronounce. Check if any name might have negative connotations in English or other languages. Return only the names that pass both checks.”

And for improving an email first draft:

“Review this email draft. Check the tone. Verify all facts and promises are accurate given the context provided. Rewrite an improved second draft.”

Notice both prompts name the exact criteria. That’s what makes them work.

But does it actually help? Measuring with evals

Here’s the honest answer: Reflection improves performance on some tasks a lot, on others a little, and on some barely at all.

Which is why before committing to it in your workflow, you should measure whether it actually helps for your specific task. Because reflection does add one extra step — meaning it takes more time and costs more compute.

The way to measure this is with evals. Here’s how it works in practice for reflection:

1. For objective tasks (where there’s a clear right or wrong answer):

Take a database query example. You run a retail store. Users ask questions like “how many items were sold in May?” or “what’s the most expensive item in inventory?”

You collect 10–15 such questions and write down the correct answers. Then you run the workflow twice: once without reflection (using the AI’s first-draft query directly) and once with reflection (letting a second AI review and improve the query before running it).

You measure the percentage of correct answers in each case.

Example: without reflection — 87% correct. With reflection — 95% correct.

That’s a meaningful jump. And now you have data, not just a hunch, to justify keeping reflection in the workflow.

2. For subjective tasks (where quality is harder to measure):

The chart quality example is a good one — how do you objectively measure whether one chart is “better” than another?

A common instinct is to ask an AI to compare two outputs and pick the better one. This sounds reasonable but has a known problem: position bias. Most LLMs, when asked to compare two options, will systematically prefer whichever one was presented first. The comparison isn’t reliable.

A better approach is grading with a rubric — evaluating each output individually against a fixed set of binary criteria, rather than comparing two outputs against each other.

For the chart example, a rubric might look like:

• Does the chart have a clear title? (yes/no)
• Are the axis labels present and readable? (yes/no)
• Is the chart type appropriate for the data? (yes/no)
• Is the legend clearly labelled? (yes/no)
• Can you compare the two years at a glance? (yes/no)

Five binary questions. Add up the score. A chart gets a 4/5 or a 5/5 — and you can compare before and after reflection using that score. This is much more reliable than asking an AI “which is better?”

The key insight: instead of asking an LLM to grade something on a vague 1–5 scale (which it’s not well calibrated on), give it 5 specific yes/no questions and add up the results. The score is more consistent and more trustworthy.

A note on using different models for generation and reflection

One thing worth experimenting with: you don’t have to use the same AI model for both steps.

Generation and reflection are different jobs. Generation needs creative output — writing, coding, producing. Reflection needs critical evaluation — spotting mistakes, checking logic, finding gaps.

Some models are better at one than the other. Reasoning models in particular tend to be very good at finding bugs in code and catching logical errors, even if they’re slower and more expensive to run.

A practical approach many builders use: use a faster, cheaper model for the first draft, and a stronger reasoning model for the reflection step. You get the best of both — speed on generation, quality on the critique.

When reflection is NOT worth it

Not everything benefits from reflection. Some things to consider:

Simple, well-defined tasks where LLMs already perform close to perfectly (basic HTML, simple calculations) may see little to no improvement from reflection — but you still pay the extra step.

Tasks with no good feedback signal — if you can’t give the AI anything new to reflect on (no error messages, no test results, no criteria), the reflection becomes the AI re-reading its own output with fresh eyes. Sometimes useful, often not.

Time-sensitive applications where every extra LLM call adds meaningful latency. Reflection doubles (at minimum) the number of AI calls in your workflow.

The right question to ask is always: does reflection actually move my eval score on this specific task? If yes, keep it. If not, skip it.

Key takeaways

• The reflection pattern is simply: generate a first draft → critique it → produce a better second draft
• It mirrors how humans naturally revise their own work
• Reflection is significantly more powerful when it has access to external feedback — error messages, test results, execution output — not just its own first draft to re-read
• You can use a different model for reflection than for generation — reasoning models are often better at finding bugs
• Specific reflection criteria outperform vague ones — tell the AI exactly what to check for
• Always measure with evals before committing to reflection in a workflow — it helps a lot on some tasks and barely at all on others
• For subjective quality evaluation, use a rubric with binary yes/no criteria instead of asking an LLM to compare two outputs side by side

What’s coming in this series

• Part 1: What is Agentic AI? Core concepts, design patterns, and the autonomy spectrum — Read Here
• Part 2 ← You’re here: The Reflection Pattern — how AI reviews and improves its own work
• Part 3: Tool Use — giving AI the ability to search, code, and act in the real world
• Part 4: Evals and Practical Tips — the disciplined process that separates good builders from great ones
• Part 5: Highly Autonomous Agents — planning, multi-agent systems, and where this is all headed

If you found this useful, follow along for Part 3 where we cover Tool Use — one of the most exciting parts of building agentic AI systems.

This article was originally published on Medium.