Reflection in AI Agents: How Agents Review, Correct, and Improve Their Work

An AI agent compares an action result with success criteria, identifies a gap, and sends a correction back into the agent loop. — Reflection is a controlled review-and-correction process, not machine self-awareness.

Reflection gives an AI agent a controlled way to inspect what happened, find a useful correction, and decide whether another attempt is worth making.

An AI agent can reason carefully, build a plan, and choose the right tool—and still get the result wrong.

A search may return weak evidence. An API may reject an argument. A generated report may omit a required section. A plan may become outdated after the environment changes. If the agent simply continues, one mistake can contaminate every later step.

Reflection is the mechanism that gives the agent a chance to notice that gap and respond to it.

The important word is chance. Reflection does not make an agent conscious, self-aware, or automatically correct. It is a designed review process: compare evidence with criteria, identify a problem, and make a bounded correction.

TL;DR

Reflection is a feedback-driven review process inside an agent loop.
It can check an output, an action, a tool result, progress toward a goal, or a completed task.
Useful reflection produces a specific change—not just “try again.”
Reflection is different from reasoning, planning, evaluation, memory, and retrying, though it can use all five.
External evidence, clear success criteria, retry limits, and stopping conditions make reflection more reliable.

What reflection means in an AI agent

An [AI agent](/what-is-an-ai-agent/) receives a goal, makes decisions, takes actions, and uses observations to decide what to do next. Reflection adds a deliberate review step to that process.

A practical definition is:

Reflection is an agent process that reviews an action, result, or trajectory against available evidence and criteria, then uses the findings to revise the output, strategy, plan, or next action.

That process may include:

Self-evaluation: judging whether the result satisfies the task.
Critique: describing what is weak, missing, inconsistent, or incorrect.
Progress checking: asking whether completed steps actually move the task toward its goal.
Mistake detection: spotting failed assumptions, invalid tool arguments, unsupported claims, or broken dependencies.
Feedback interpretation: converting a tool error, test failure, evaluator score, or human comment into an actionable lesson.
Retry decisions: deciding whether another attempt has a reasonable chance of improving the result.
Strategy revision: changing the method instead of merely regenerating the same answer.
Iterative improvement: repeating review and revision until the result is acceptable or a limit is reached.

Reflection can be a prompt to the same language model, a separate critic model, a set of deterministic checks, a tool-assisted verification step, human feedback, or a combination of these.

The practical reflection loop

The core loop is:

Act → Observe Result → Evaluate → Identify Problems → Revise Strategy or Output → Retry/Continue

Six-stage AI agent reflection loop: Act, Observe Result, Evaluate, Identify Problems, Revise Strategy or Output, then Retry or Continue. — A useful reflection loop turns evidence into a specific correction before the agent retries or continues.

A useful reflection loop turns evidence into a specific correction before the agent retries or continues.

1. Act

The agent performs an action: generate an answer, call a tool, update a record, run code, or complete a planned step.

2. Observe result

The agent captures what actually happened. An observation may be:

a tool response;
a validation error;
test output;
retrieved evidence;
a changed system state;
human feedback;
the agent’s own draft.

This is part of the broader [agent execution loop](/how-ai-agents-work/). Without an observation, the agent has little reliable material to reflect on.

3. Evaluate

The result is compared with explicit criteria. For example:

Did the API call succeed?
Does the answer address every requested point?
Are claims supported by the retrieved sources?
Did the code pass its tests?
Is the agent still within its permissions, time, and cost limits?

The stronger the criteria, the less reflection depends on vague model judgment.

4. Identify problems

The agent names the gap precisely:

“The search result is about the wrong company.”
“The API rejected the date because it is not in ISO format.”
“The report contains revenue but not the requested growth rate.”
“The proposed action would exceed the approved permission boundary.”

“The answer could be better” is not a useful diagnosis.

5. Revise strategy or output

The agent turns the diagnosis into a change. It may:

rewrite part of the output;
correct a tool argument;
select another tool;
retrieve stronger evidence;
reorder tasks;
update a subgoal;
return to an earlier checkpoint;
ask a human for missing information.

If the problem affects the route to the goal, reflection may trigger [dynamic replanning](/planning-in-ai-agents/).

6. Retry or continue

The agent decides among four common outcomes:

Accept: the result meets the criteria.
Revise locally: fix only the affected part.
Retry strategically: make another attempt with a meaningful change.
Stop or escalate: the limit is reached, the risk is too high, or human judgment is required.

The last option matters. Reflection without a stopping condition can become an expensive loop that never converges.

A simple example: improving a customer reply

Suppose an agent must draft a reply to a customer asking for a refund.

First action: The agent writes a polite response explaining the refund process.

Observation: The draft is fluent, but the customer specifically asked when the refund will arrive.

Evaluation: The response is polite and accurate, but it does not fully answer the customer’s question.

Problem identified: The expected timeline is missing.

Revision: The agent retrieves the approved refund-time policy and adds the correct time range.

Continue: The revised answer now satisfies the request and can move to approval or sending.

Reflection did not require a new master plan. It found a local omission and corrected it.

A complex example: reviewing a research agent’s execution

Now consider a research agent preparing a market-entry brief.

Its [plan](/planning-in-ai-agents/) is:

define the market and time period;
collect regulatory sources;
gather competitor and pricing data;
compare opportunities and risks;
write the recommendation.

After the first three steps, the agent reaches a checkpoint.

Observation: It has many news articles but only one primary regulatory source. Two competitor prices are in different currencies, and one is from an outdated page.

Evaluation: The evidence is not strong or comparable enough to support the final recommendation.

Problems identified:

weak source quality for regulation;
inconsistent currency basis;
stale competitor evidence.

Revised strategy:

search official regulator publications;
normalize all prices to one currency and reference date;
replace the stale page with a current first-party source;
delay recommendation writing until the evidence checks pass.

Continue: The agent updates its state, revises the affected plan steps, and resumes research.

This is more than editing prose. Reflection reviews the execution trajectory and changes how the task proceeds.

Where reflection can occur

Reflection is not limited to the end of a task.

Reflection point	What the agent checks	Example response
Before an action	Assumptions, permissions, risk, and likely consequences	“This action deletes data; request approval first.”
After an action	Whether the action produced the intended state change	“The record was created, but the owner field is empty.”
After a tool result	Tool success, relevance, completeness, and trustworthiness	“Search returned a namesake company; refine the query.”
After a failed step	Failure cause and whether a changed attempt could work	“Authentication failed; retrying the same request will not help.”
After completing a task	Whether the final deliverable satisfies the full request	“The analysis is complete, but the executive summary is missing.”
Across repeated tasks	Recurring patterns that should change future behavior	“This data source is frequently stale; verify its date before use.”

Before action: anticipatory reflection

The agent pauses before a consequential action and checks whether its assumptions are sound. This is useful for irreversible changes, external communication, payments, or operations with strict permissions.

It should not become a second full planning cycle before every trivial step. Use it where the cost of a mistake justifies the check.

During execution: checkpoint reflection

At selected checkpoints, the agent reviews progress, state, remaining constraints, and plan validity. A checkpoint is especially useful after expensive tool calls or before downstream steps depend on earlier results.

After action: retrospective reflection

The agent reviews the output or trajectory after the fact. It may correct the current result, extract a lesson for a future attempt, or both.

Two useful reflection patterns

Pattern 1: critique and revise

This pattern focuses on an output.

Generate a draft.
Evaluate it against a rubric or constraints.
Produce a specific critique.
Revise only the parts affected by the critique.
Recheck the revised output.

Research systems such as Self-Refine explore this iterative feedback-and-refinement pattern without requiring model-weight updates. The practical lesson is not that a model can always judge itself correctly; it is that separating generation, critique, and revision can create a more inspectable improvement process.

This pattern works well for:

reports and summaries;
code with testable requirements;
structured extraction;
answers with a clear rubric;
formatting and completeness checks.

Pattern 2: execution review

This pattern focuses on actions and progress rather than only the final output.

Review the goal, plan, and current [agent state](/anatomy-of-an-ai-agent/).
Inspect completed actions and their observations.
Find the earliest important divergence from expectations.
Decide whether to repair locally, return to a checkpoint, replan, or stop.
Record only the lesson that will matter later.

This is useful for long-running research, coding, operations, and multi-tool tasks.

The Reflexion research framework is one example of using task feedback to create verbal reflections that can influence later trials through an episodic memory buffer. That is a particular technique, not a universal definition of reflection.

Reflection is not magical self-awareness

Words such as reflection, self-evaluation, and self-critique are convenient engineering labels. They do not prove that an agent:

has subjective experience;
understands itself as a person would;
knows whether its internal explanation is faithful;
can reliably discover every mistake;
becomes permanently smarter after one review.

In many systems, “reflection” simply means sending the output, criteria, and observations through another model call. In stronger designs, that call is grounded by test results, tool responses, source evidence, deterministic rules, or human feedback.

The mechanism matters more than the metaphor.

Reflection compared with related concepts

Concept	Primary question	Typical output
Reasoning	“What does this situation mean, and what should I infer or decide?”	An interpretation or decision
Planning	“What sequence of tasks should achieve the goal?”	A plan, subgoals, dependencies, or priorities
Evaluation	“How well did this result meet the criteria?”	A score, label, pass/fail result, or judgment
Memory	“What past information should be available now or later?”	Retrieved context or stored information
Retrying	“Should the action be attempted again?”	Another execution attempt
Reflection	“What does the evidence say went wrong or could improve, and what should change?”	A critique, lesson, correction, or revised strategy

Reflection vs reasoning

[Reasoning](/reasoning-in-ai-agents/) helps the agent interpret a situation and choose what to do. Reflection is reasoning applied to the agent’s own output, action, progress, or trajectory after—or sometimes just before—execution.

An agent can reason without reflecting. For example, it may choose a database query based on the user’s request. It reflects when it reviews the returned rows, notices that a date filter excluded the latest period, and changes the query.

Reflection vs planning

Planning creates or updates the route to a goal. Reflection judges what happened and identifies what should change.

Reflection may trigger replanning, but it may also produce a small correction that leaves the plan untouched.

Reflection vs evaluation

Evaluation produces a judgment: “the answer failed two rubric items.”

Reflection interprets that judgment and proposes an actionable response: “retrieve the missing source, rewrite the unsupported paragraph, and recheck only the affected claims.”

Evaluation can happen without reflection. Reflection normally needs some form of evaluation.

Reflection vs memory

[Memory](/memory-in-ai-agents/) stores or retrieves information across steps or tasks. Reflection produces a lesson or correction. That lesson may be written to memory, but it should not be stored automatically.

Weak or overly specific reflections can pollute future context. A memory policy should decide whether a lesson is reliable, reusable, and worth retaining.

Reflection vs retrying

Retrying repeats an action. Reflection explains why another attempt is justified and what will be different.

If the agent calls the same failing API with the same invalid arguments five times, it is retrying without useful reflection. If it reads the error, corrects the date format, and tries once more, reflection has improved the retry.

Feedback makes reflection stronger

Reflection quality depends heavily on the signal available to the agent.

From weakest to strongest, common signals include:

Ungrounded self-critique: the model reviews its own answer without new evidence.
Explicit rubric: the output is checked against defined requirements.
Environment feedback: the agent receives an API result, test failure, or changed state.
Tool-assisted verification: calculations, search, databases, compilers, or validators check claims.
Independent review: another model, evaluator, or human examines the result.
Objective outcome: the environment confirms success or failure.

Tool feedback is especially useful because it can expose errors the model may not detect from text alone. A coding agent can run tests. A research agent can verify a claim against a primary source. A data agent can compare row counts before and after a transformation. This connects reflection directly to [tool use](/tool-use-in-ai-agents/).

What should be stored after reflection?

Not every critique belongs in long-term memory.

A reflection is a good memory candidate when it is:

supported by evidence;
likely to matter in future tasks;
phrased as a reusable lesson;
scoped to the right user, system, or environment;
safe to retain;
replaceable when circumstances change.

For example:

Weak: “The last report was bad.”
Better: “When comparing regional prices, normalize currency and reference date before calculating differences.”

The second statement is actionable and reusable. Even then, the system should track its scope and allow it to be updated or forgotten.

Limitations and failure modes

Incorrect self-critique

The agent may label a correct result as wrong or invent a flaw that does not exist. Research on intrinsic self-correction has found that language models can struggle to improve reasoning without external feedback and may sometimes degrade a correct answer.

Design response: ground critique in tests, evidence, rubrics, or independent review.

Endless reflection loops

The agent keeps finding minor issues, revising, and reviewing without reaching a stopping condition.

Design response: set a maximum number of reflection cycles, improvement threshold, deadline, or cost budget.

Unnecessary retries

The agent retries even when nothing material will change—for example, when credentials are missing or a required decision belongs to a human.

Design response: require each retry to state the diagnosed cause and the specific change in the next attempt.

Compounding errors

An incorrect critique produces a bad revision, which becomes the basis for another bad critique. If the lesson is stored, the error may affect future tasks too.

Design response: return to trusted checkpoints, preserve original evidence, and validate lessons before writing them to persistent memory.

Excessive token, latency, and cost usage

Every critique and revision may require another model call, tool call, or context replay. Reflection can cost more than the task itself.

Design response: use reflection selectively—after risky steps, failures, checkpoints, or outputs with clear quality requirements.

False confidence

A polished self-critique can sound convincing even when it misses the real problem. Fluency is not verification.

Design response: expose evidence and uncertainty, and escalate high-stakes decisions to qualified human review.

When reflection is useful—and when it is not

Reflection is most useful when:

the task is multi-step or expensive;
errors can propagate;
success criteria are available;
the environment provides feedback;
another attempt can meaningfully change the result;
quality matters more than minimal latency.

It may be unnecessary when:

the task is simple and low-risk;
a deterministic check already gives a complete answer;
the first result clearly satisfies the criteria;
the action cannot be safely reversed or retried;
reflection would cost more than the potential improvement.

More reflection is not automatically better. The right question is: Will another review create new, trustworthy information that can change the next action?

A practical design checklist

When adding reflection to an agent, define:

Trigger: What event starts reflection—a failure, checkpoint, risk threshold, or final review?
Target: Is the agent reviewing an output, tool call, plan, state transition, or full trajectory?
Criteria: What does acceptable performance mean?
Evidence: What observations, sources, tests, or feedback are available?
Correction space: What may the agent change?
Memory rule: Which lessons, if any, should persist?
Retry rule: What must be different before another attempt?
Stopping condition: When must the agent accept, stop, or escalate?
Budget: How much time, cost, and context may reflection consume?
Audit trail: Can a reviewer see the failure, critique, correction, and outcome?

These controls turn reflection from a vague prompt into an observable system behavior.

My Take

Reflection is most valuable as a control mechanism, not as a claim about intelligence.

The weakest implementation says, “Check your work again.” The strongest implementation defines what to inspect, provides evidence, limits what can change, and decides when to stop. In production, a small reflection step grounded in a test or tool result is often more useful than a long, ungrounded internal critique.

The goal is not to make the agent doubt every action. It is to place disciplined review at the moments where mistakes are detectable, correctable, and costly enough to matter.

The mental model to keep

Reflection closes the gap between what the agent intended and what actually happened.

Remember the loop: