Reflection & Self-Correction in AI Agents¶

Reflection enables an AI Agent to evaluate its own actions and outcomes, identify errors or weaknesses, and determine whether corrective action, re-planning, or escalation is required.

📖 Overview¶

Planning determines what the agent intends to do.

Reasoning determines what action the agent should take.

Reflection determines:

Did the action produce the expected result, and what should the agent do next?

A production AI Agent therefore operates through a feedback loop:

Goal
 ↓
Plan
 ↓
Reason
 ↓
Act
 ↓
Observe
 ↓
Reflect
 ↓
Evaluate
 ↓
 ┌───────────────┐
 │               │
Success        Problem
 │               │
 ↓               ↓
Continue      Correct
                 ↓
              Re-plan
                 ↓
              Re-execute

Reflection and self-correction are important because real-world agent execution is rarely perfectly predictable.

Tools can fail.

Data can be incomplete.

Plans can become invalid.

Actions can produce unexpected results.

A production agent therefore needs mechanisms to detect these situations and recover safely.

🎯 Learning Objectives¶

After completing this chapter, you will understand:

What reflection means in AI Agents
What self-correction means
Why agents need feedback loops
Reflection vs reasoning
Reflection vs re-planning
Reflection vs retry
Outcome evaluation
Error detection
Critique-based reflection
Self-correction patterns
Tool-result validation
Plan validation after execution
Iterative improvement
Reflection loops
Guarding against infinite correction loops
Cost and latency implications
Production reflection architecture
Observability of reflection
Safe enterprise self-correction

1. What Is Reflection?¶

Reflection is the process through which an agent evaluates an action, intermediate result, or final result against the intended objective.

A simplified model is:

Action
 ↓
Result
 ↓
Evaluate
 ↓
Compare with Goal
 ↓
Identify Issues
 ↓
Determine Next Step

For example:

Goal:
Generate a customer report

Agent Action:
Retrieve customer data

Result:
Only 30% of expected records returned

Reflection:
Result may be incomplete

Next Decision:
Investigate data source

Reflection therefore introduces a feedback mechanism into agent execution.

2. What Is Self-Correction?¶

Self-correction is the ability of an agent to modify its behavior after detecting a problem.

Conceptually:

Attempt
 ↓
Evaluate
 ↓
Failure Detected
 ↓
Identify Cause
 ↓
Correct Strategy
 ↓
Retry / Re-plan
 ↓
Evaluate Again

For example:

Initial Approach
 ↓
Database Query
 ↓
No Results
 ↓
Self-Correction
 ↓
Check Query Parameters
 ↓
Correct Query
 ↓
Execute Again

The important distinction is:

Retry repeats an action; self-correction changes the approach when necessary.

3. Why Do Agents Need Reflection?¶

Without reflection, an agent may assume that every action succeeded.

Plan
 ↓
Execute
 ↓
Assume Success
 ↓
Continue

This can cause cascading failures.

A reflective agent instead uses:

Plan
 ↓
Execute
 ↓
Observe
 ↓
Validate
 ↓
Reflect
 ↓
Continue / Correct

Reflection can help detect:

Incorrect tool results
Incomplete information
Invalid assumptions
Failed actions
Incorrect task completion
Poor-quality intermediate results
Policy violations
Unexpected environment changes

4. Reflection in the Agent Loop¶

A complete execution loop can be represented as:

┌───────────────┐
│     Goal      │
└───────┬───────┘
        ↓
┌───────────────┐
│     Plan      │
└───────┬───────┘
        ↓
┌───────────────┐
│    Reason     │
└───────┬───────┘
        ↓
┌───────────────┐
│     Act       │
└───────┬───────┘
        ↓
┌───────────────┐
│    Observe    │
└───────┬───────┘
        ↓
┌───────────────┐
│   Reflect     │
└───────┬───────┘
        ↓
   ┌────┴───────┐
   ↓            ↓
Success       Problem
   ↓            ↓
Continue      Correct
                ↓
             Re-plan
                ↓
             Execute

Reflection therefore creates a closed-loop agent architecture.

5. Reflection vs Reasoning¶

These concepts are related but different.

Reasoning¶

Reasoning asks:

What should I do?

Current State
 ↓
Evaluate Options
 ↓
Select Action

Reflection¶

Reflection asks:

Did what I just did work?

Action
 ↓
Result
 ↓
Evaluate Outcome

Together:

Reason
 ↓
Act
 ↓
Observe
 ↓
Reflect
 ↓
Reason Again

A useful mental model is:

Reasoning → Decision

Reflection → Evaluation

6. Reflection vs Planning¶

Planning determines the intended execution sequence.

Goal
 ↓
Plan
 ↓
Task A
 ↓
Task B
 ↓
Task C

Reflection evaluates whether that plan is still valid.

Plan
 ↓
Execute
 ↓
Observe
 ↓
Reflect
 ↓
Plan still valid?

If yes:

Continue

If no:

Re-plan

Therefore:

Planning
   ↓
Execution
   ↓
Reflection
   ↓
Re-planning

Reflection provides the feedback necessary for dynamic planning.

7. Reflection vs Retry¶

Retry and self-correction should not be treated as the same mechanism.

Retry¶

Repeats the same operation.

Tool Call
 ↓
Failure
 ↓
Retry Same Tool

Self-Correction¶

Changes the strategy.

Tool Call
 ↓
Failure
 ↓
Evaluate Cause
 ↓
Change Strategy
 ↓
Alternative Action

For example:

Retry:

Database Query
      ↓
Failure
      ↓
Database Query Again

Self-correction:

Database Query
      ↓
Failure
      ↓
Check Query
      ↓
Correct Parameters
      ↓
Execute Again

Or:

Database Query
      ↓
Database Unavailable
      ↓
Alternative Approved Source

8. Reflection vs Error Handling¶

Traditional software systems typically handle known errors using deterministic logic.

try
 ↓
operation
 ↓
catch
 ↓
fallback

Agent reflection adds a more adaptive layer:

Action
 ↓
Result
 ↓
Evaluate
 ↓
Determine What Went Wrong
 ↓
Choose Recovery Strategy

The two approaches can coexist.

Deterministic Error Handling
            +
Agent Reflection
            ↓
Controlled Recovery

Deterministic mechanisms should remain responsible for predictable infrastructure failures.

Agent reflection is more appropriate when interpretation or strategy needs to change.

9. What Can an Agent Reflect On?¶

Reflection can occur at several levels.

Action-Level Reflection¶

Did this action succeed?

Tool-Level Reflection¶

Did the tool return a valid result?

Task-Level Reflection¶

Was the task completed successfully?

Plan-Level Reflection¶

Is the current plan still valid?

Goal-Level Reflection¶

Has the overall objective been achieved?

This creates a hierarchy:

Goal
 ↓
Plan
 ↓
Task
 ↓
Action
 ↓
Tool

Reflection can be applied at each level.

10. Outcome Validation¶

Reflection requires some mechanism for determining whether an outcome is acceptable.

For example:

Expected:
100 customer records

Actual:
32 records

Validation:
FAIL

Or:

Expected:
HTTP 200

Actual:
HTTP 500

Validation:
FAIL

Or:

Expected:
Payment completed

Actual:
Payment pending

Validation:
INCOMPLETE

The agent can therefore use:

Expected Outcome
      ↓
Actual Outcome
      ↓
Validation
      ↓
Reflection

11. Reflection Criteria¶

A production agent should define what constitutes success.

Possible criteria include:

Task Completion
Correctness
Completeness
Accuracy
Policy Compliance
Data Validation
Business Rules
Tool Result Status
User Requirements

For example:

Task:
Generate financial report

Success Criteria:
✓ All required data retrieved
✓ Calculations completed
✓ Validation passed
✓ Required sections generated
✓ Policy requirements satisfied

Reflection can evaluate the result against these criteria.

12. Critique-Based Reflection¶

One common pattern is to generate a result and then evaluate it using a critique step.

Generate Result
      ↓
Critic / Evaluator
      ↓
Identify Problems
      ↓
Correct
      ↓
Generate Improved Result

Conceptually:

Agent
 ↓
Draft
 ↓
Critique
 ↓
Improve
 ↓
Validate

The critic may evaluate:

Correctness
Completeness
Relevance
Consistency
Policy compliance

13. Critique → Correction Loop¶

A more complete pattern is:

              ┌──────────────┐
              │   Generate   │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │    Critique  │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │   Evaluate   │
              └──────┬───────┘
                     ↓
                ┌────┴────┐
                ↓         ↓
              Pass       Fail
                ↓         ↓
             Complete   Correct
                          ↓
                       Generate

This can be useful when the output has clearly defined evaluation criteria.

14. Self-Correction Through Re-Planning¶

Self-correction does not always require modifying the immediate action.

Sometimes the agent needs to revise the entire plan.

Initial Plan
     ↓
Execute Task A
     ↓
Unexpected Result
     ↓
Reflect
     ↓
Current Plan Invalid
     ↓
Generate New Plan
     ↓
Execute Alternative

For example:

Plan:
Retrieve database data
 ↓
Analyze data
 ↓
Generate report

Problem:
Database unavailable

Reflection:
Original data source cannot be used

Correction:
Use approved replica
 ↓
Continue

This connects reflection directly to planning.

15. Reflection with Tool Results¶

Tool results should be validated before the agent uses them for subsequent decisions.

Tool
 ↓
Result
 ↓
Validate
 ↓
Reflect
 ↓
Use Result

Example:

Search API
 ↓
Empty Result
 ↓
Reflection
 ↓
Was query too restrictive?
 ↓
Modify Query
 ↓
Search Again

This is safer than assuming:

No Result = No Data

because an empty result may indicate:

Wrong query
Wrong parameters
Temporary failure
Incorrect filters
Missing permissions
Actual absence of data

16. Reflection with Structured Outputs¶

Structured results make reflection easier.

For example:

{
  "status": "partial",
  "records_found": 32,
  "records_expected": 100,
  "complete": false
}

The reflection layer can evaluate:

complete = false

and trigger:

Investigation

Structured outputs improve:

Validation
Automation
Testing
Observability
Recovery

17. Reflection with Memory¶

Reflection can produce information that should be stored for future execution.

For example:

Attempt
 ↓
Failure
 ↓
Reflection
 ↓
Cause Identified
 ↓
Correction
 ↓
Memory

The memory may store:

Previous Strategy
Failure
Successful Alternative

Future executions can then avoid repeating the same mistake.

Conceptually:

Past Experience
      ↓
Memory
      ↓
Future Agent
      ↓
Better Decision

However, not every reflection should become long-term memory.

Memory should be selectively managed based on:

Relevance
Durability
Confidence
Privacy
Storage cost

18. Reflection and Agent State¶

Reflection should update the agent's state.

Example:

Task Status:
RUNNING

After successful reflection:

Task Status:
COMPLETED

After detecting a problem:

Task Status:
NEEDS_CORRECTION

Possible state transitions:

PENDING
  ↓
RUNNING
  ↓
OBSERVING
  ↓
REFLECTING
  ↓
 ┌──────────────┬──────────────┐
 ↓              ↓              ↓
COMPLETED   NEEDS_CORRECTION  FAILED
                ↓
             RE-PLANNING
                ↓
             RUNNING

This provides a structured execution model.

19. Reflection Granularity¶

Reflection can happen at different frequencies.

Per Action¶

Action
 ↓
Reflect

Provides strong control but may be expensive.

Per Task¶

Several Actions
 ↓
Task Result
 ↓
Reflect

Balances control and cost.

Per Plan¶

Plan Execution
 ↓
Reflect

Cheaper but may detect errors later.

Final Outcome¶

Complete Run
 ↓
Evaluate

Useful for overall evaluation but insufficient for early error recovery.

A production system should choose the appropriate granularity based on risk and task complexity.

20. Adaptive Reflection¶

Not every action requires the same amount of reflection.

A low-risk operation may use:

Execute
 ↓
Basic Validation

A high-risk operation may use:

Execute
 ↓
Validate
 ↓
Critique
 ↓
Policy Check
 ↓
Human Approval

This creates risk-based reflection.

Risk
 │
 │          High
 │           │
 │        Extensive
 │        Reflection
 │           │
 │     Medium
 │       Reflection
 │
 │ Low
 │  Basic Validation
 └────────────────────→

The goal is to avoid unnecessary overhead while maintaining appropriate safety.

21. Reflection and Guardrails¶

Reflection should not replace security guardrails.

Consider:

Agent Decision
      ↓
Reflection
      ↓
Policy Validation
      ↓
Execution

Reflection asks:

"Is this a good action?"

Policy asks:

"Is this action allowed?"

These are different concerns.

A better architecture is:

Decision
 ↓
Reflection / Evaluation
 ↓
Policy
 ↓
Authorization
 ↓
Execution

The security controls remain authoritative.

22. Reflection and Human Escalation¶

Self-correction should have an escalation boundary.

Agent
 ↓
Attempt
 ↓
Reflect
 ↓
Problem
 ↓
Correct
 ↓
Retry
 ↓
Reflect Again

If repeated correction fails:

Maximum Attempts Reached
          ↓
       Escalate
          ↓
     Human Review

This prevents an agent from endlessly attempting increasingly risky actions.

23. Correction Strategies¶

When reflection detects a problem, several strategies are possible.

Retry¶

Repeat same operation

Modify Input¶

Correct arguments

Use Alternative Tool¶

Tool A
 ↓
Failure
 ↓
Tool B

Retrieve More Information¶

Missing Context
 ↓
Retrieve Additional Data

Re-plan¶

Current Plan
 ↓
Invalid
 ↓
New Plan

Ask User¶

Required Information Missing
 ↓
Clarification

Escalate¶

High Risk / Unresolved
 ↓
Human

A production agent should select the appropriate correction strategy rather than blindly retrying.

24. Self-Correction Decision Tree¶

                 Problem Detected
                        │
                        ▼
                 Is it transient?
                   /        \
                 Yes         No
                 /            \
              Retry        Diagnose
                             │
                             ▼
                     Can strategy change?
                        /          \
                      Yes          No
                      /              \
                  Re-plan          Escalate
                    │
                    ▼
                 Execute
                    │
                    ▼
                 Reflect

This creates controlled recovery.

25. Reflection Loops¶

A reflection loop can be represented as:

Generate
   ↓
Evaluate
   ↓
Improve
   ↓
Evaluate
   ↓
Improve
   ↓
...

Without a termination condition, this can become problematic.

Production systems should define:

Maximum Reflection Iterations
Maximum Runtime
Maximum Token Budget
Maximum Cost
Minimum Improvement Threshold

Example:

Reflection Limit = 3

If the result does not improve after three attempts:

Stop
 ↓
Return Best Valid Result
      OR
Escalate

26. Avoiding Infinite Self-Correction¶

A common failure pattern is:

Attempt
 ↓
Failure
 ↓
Correct
 ↓
Failure
 ↓
Correct
 ↓
Failure
 ↓
Correct
 ↓
...

This creates:

Token waste
Increased latency
Increased cost
Unpredictable behavior

Controls should include:

Attempt Limit
Iteration Limit
Time Limit
Cost Limit
Progress Detection
Repeated-Action Detection

27. Progress Detection¶

The agent should determine whether correction is actually improving the situation.

Example:

Attempt 1
Score = 40%

Attempt 2
Score = 55%

Attempt 3
Score = 70%

Attempt 4
Score = 71%

At some point, additional reflection may provide little value.

A production system can define:

Minimum Improvement Threshold

If improvement is below the threshold:

Stop
 ↓
Return / Escalate

28. Reflection Cost¶

Reflection usually requires additional computation.

A basic execution might be:

Task
 ↓
LLM
 ↓
Tool
 ↓
Result

A reflective execution may become:

Task
 ↓
LLM
 ↓
Tool
 ↓
Result
 ↓
LLM Reflection
 ↓
LLM Correction
 ↓
Tool
 ↓
Result

This can increase:

Token usage
LLM calls
Latency
Infrastructure cost

Therefore:

Reflection should be introduced where its reliability benefit justifies its operational cost.

29. Reflection vs Deterministic Validation¶

Some outcomes can be validated deterministically.

For example:

Expected:
HTTP 200

Actual:
HTTP 500

No LLM reflection is required to identify the failure.

Similarly:

Expected records = 100
Actual records = 100

can be validated through code.

A better architecture is:

Deterministic Validation
        ↓
If Ambiguous
        ↓
Agent Reflection

This avoids unnecessary LLM calls.

30. Hybrid Self-Correction Architecture¶

A production system can combine deterministic validation with model-based reflection.

                       Agent Action
                            │
                            ▼
                       Tool Result
                            │
                            ▼
                  Deterministic Validator
                            │
                    ┌───────┴───────┐
                    ↓               ↓
                  Valid           Invalid /
                    │             Ambiguous
                    │               │
                    │               ▼
                    │          Agent Reflection
                    │               │
                    │          ┌────┴────┐
                    │          ↓         ↓
                    │       Correct    Escalate
                    │          │
                    └──────────┴──────→ Continue

This is generally more predictable than relying exclusively on model-based reflection.

31. Reflection Observability¶

Reflection should be visible in agent telemetry.

Useful events include:

Reflection Started
Reflection Result
Issue Detected
Correction Selected
Re-plan Triggered
Retry Triggered
Escalation Triggered
Reflection Completed

A trace might look like:

Agent Run
 │
 ├── Task Started
 ├── Tool Call
 ├── Tool Result
 ├── Validation Failed
 ├── Reflection
 ├── Correction
 ├── Tool Call
 ├── Tool Result
 ├── Validation Passed
 └── Task Completed

This allows engineers to understand why the agent changed its behavior.

32. Reflection Metrics¶

Useful metrics include:

Reflection Rate
Correction Rate
Successful Correction Rate
Re-plan Rate
Retry Rate
Escalation Rate
Average Reflection Iterations
Average Recovery Time
Reflection Token Usage
Reflection Cost

For example:

Correction Success Rate
=
Successful Corrections
÷
Total Correction Attempts

These metrics help determine whether reflection is actually improving reliability.

33. Reflection Evaluation¶

Reflection itself should be evaluated.

Questions include:

Did the agent detect the actual problem?
Did it identify the correct cause?
Did it select an appropriate correction?
Did the correction improve the outcome?
Did it introduce a new problem?
Did it respect policy?
Did it stop when further correction was ineffective?

This means:

Agent
 ↓
Reflection
 ↓
Correction
 ↓
Outcome
 ↓
Evaluation

Reflection should therefore be treated as an engineering capability that requires testing.

34. Practical Example — Customer Support Agent¶

Consider:

"My payment failed. Please fix it."

The agent executes:

Retrieve Payment
      ↓
Payment Status = FAILED
      ↓
Reflect
      ↓
Retrieve Failure Reason
      ↓
Error = Temporary Processor Failure
      ↓
Reflect
      ↓
Determine Retry Is Allowed
      ↓
Retry Payment
      ↓
Payment = SUCCESS
      ↓
Validate
      ↓
Respond

If the retry fails:

Retry
 ↓
Failure
 ↓
Reflect
 ↓
Second Retry Not Allowed
 ↓
Escalate

The agent therefore performs controlled recovery rather than unlimited retries.

35. Practical Example — Software Engineering Agent¶

Consider:

"Fix the failing unit test."

The agent may execute:

Run Tests
   ↓
Failure Detected
   ↓
Reflect
   ↓
Inspect Stack Trace
   ↓
Identify Likely Cause
   ↓
Modify Code
   ↓
Run Tests

Suppose:

Tests Still Fail

The agent reflects again:

Previous Hypothesis Incorrect
        ↓
Inspect Additional Code
        ↓
Update Hypothesis
        ↓
Modify Fix
        ↓
Run Tests

If tests pass:

Validate
 ↓
Complete

If the agent cannot make progress:

Escalate

36. Practical Example — RAG Agent¶

Consider:

"Summarize the company's refund policy."

The agent retrieves documents.

Query
 ↓
Retrieve Documents
 ↓
Generate Answer
 ↓
Reflect

Reflection may check:

Are all claims supported?
Are citations present?
Are there contradictions?
Is the answer complete?

If unsupported claims are detected:

Reflection
 ↓
Identify Unsupported Claim
 ↓
Retrieve Additional Context
 ↓
Regenerate
 ↓
Validate

This demonstrates how reflection can complement RAG.

37. Reflection and Agent Memory¶

Reflection can produce valuable information, but memory should not blindly store every correction.

A useful architecture is:

Reflection
     ↓
Candidate Memory
     ↓
Memory Validation
     ↓
Relevance / Confidence Check
     ↓
Memory Store

Potential memory:

Successful Strategy
Known Failure
User Preference
Verified Fact

Sensitive or temporary execution details may not belong in long-term memory.

38. Reflection and Security¶

Self-correction must not bypass security controls.

Consider:

Agent
 ↓
Action Rejected
 ↓
Reflection
 ↓
Alternative Action

The alternative action must still pass:

Authorization
Policy
Guardrails
Tool Security
Data Access Controls

Therefore:

Reflection
    ↓
Cannot Override
    ↓
Security Boundary

This is essential for enterprise agents.

39. Reflection and Human-in-the-Loop¶

For high-risk situations:

Agent
 ↓
Reflection
 ↓
Unresolved / High Risk
 ↓
Human Review
 ↓
Approve / Reject

The human should receive useful context:

Original Goal
Current State
Actions Taken
Failure
Correction Attempts
Proposed Next Action
Risk

This makes escalation actionable rather than simply reporting:

"Agent failed."

40. Enterprise Reflection Architecture¶

A production-oriented architecture can separate execution, validation, reflection, and policy.

                         Agent
                           │
                           ▼
                      Plan / Reason
                           │
                           ▼
                         Action
                           │
                           ▼
                     Tool / Service
                           │
                           ▼
                         Result
                           │
                           ▼
                Deterministic Validator
                           │
                    ┌──────┴──────┐
                    ↓             ↓
                  Valid       Invalid /
                    │          Ambiguous
                    │             │
                    │             ▼
                    │         Reflection
                    │             │
                    │       ┌─────┼─────┐
                    │       ↓     ↓     ↓
                    │     Retry Re-plan Escalate
                    │       │     │
                    │       └─────┼─────┘
                    │             ↓
                    │        Policy Check
                    │             │
                    └─────────────┴──────→ Continue

This provides:

Execution
 +
Validation
 +
Reflection
 +
Correction
 +
Policy

as separate architectural concerns.

41. Reflection Lifecycle¶

The complete reflection lifecycle can be represented as:

                  Execute
                     │
                     ▼
                  Observe
                     │
                     ▼
                  Validate
                     │
                     ▼
                 Reflect
                     │
             ┌───────┴────────┐
             ↓                ↓
          Success           Problem
             │                │
             ↓                ▼
         Continue          Diagnose
                              │
                    ┌─────────┼─────────┐
                    ↓         ↓         ↓
                  Retry     Re-plan   Escalate
                    │         │
                    └────┬────┘
                         ↓
                      Execute
                         │
                         ▼
                      Reflect

42. Production Guardrails¶

Reflection should operate within explicit limits.

Recommended controls include:

Maximum Reflection Iterations
Maximum Correction Attempts
Maximum Tool Calls
Maximum Runtime
Maximum Token Budget
Maximum Cost
Maximum Re-plan Count
Maximum Escalation Delay

Also detect:

Repeated Action
Repeated Failure
No Progress
Conflicting Corrections
Policy Violation
Unsafe Escalation

When limits are reached:

Stop
 ↓
Return Safe Result
      OR
Escalate

43. Key Engineering Principles¶

1. Reflection Must Have a Purpose¶

Do not introduce reflection simply because an agent can reflect.

Use it where it improves reliability or task quality.

2. Validate Before Reflecting¶

Use deterministic validation whenever possible.

3. Separate Retry from Correction¶

Retry repeats.

Correction changes the approach.

4. Re-Plan When the Strategy Is Invalid¶

Do not keep executing an obsolete plan.

5. Use Risk-Based Reflection¶

High-risk operations require stronger validation and recovery controls.

6. Bound Reflection Loops¶

Always define iteration, time, token, and cost limits.

7. Measure Improvement¶

Correction should produce measurable progress.

8. Preserve Security Boundaries¶

Reflection must never bypass authorization or policy controls.

9. Observe Recovery¶

Reflection and correction events should be part of the agent trace.

10. Escalate When Necessary¶

A reliable agent knows when it cannot safely recover.

44. Reflection Architecture Pattern¶

The core pattern can be summarized as:

                ┌──────────────┐
                │     Goal     │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │     Plan     │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │    Reason    │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │     Act      │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │   Observe    │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │  Validate    │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │   Reflect    │
                └──────┬───────┘
                       ↓
              ┌────────┴────────┐
              ↓                 ↓
           Success            Problem
              ↓                 ↓
          Continue          Correct
                                ↓
                             Re-plan
                                ↓
                             Execute

This feedback loop is one of the most important foundations for reliable AI Agent execution.

45. Part VI → Part VII Boundary¶

Reflection and self-correction belong to Part VI — AI Agents because they are fundamental capabilities of an individual agent.

Part VI
Individual Agent
      │
      ├── Planning
      ├── Reasoning
      ├── Reflection
      ├── Self-Correction
      ├── Memory
      ├── Tools
      └── Execution

Part VII will extend these capabilities into autonomous systems:

Part VII
Agentic AI
      │
      ├── Multiple Agents
      ├── Delegation
      ├── Supervision
      ├── Collaboration
      ├── Autonomous Workflows
      ├── Long-Running Agents
      ├── Agentic RAG
      └── Enterprise Agent Platforms

Protocols such as A2A and other agent communication protocols remain part of Part VII.

📌 Key Takeaways¶

Reflection evaluates whether an agent's action or outcome achieved the intended objective.
Self-correction allows the agent to modify its behavior after detecting a problem.
Reflection closes the loop between execution and future decisions.
Reflection is different from reasoning, planning, retry, and deterministic error handling.
Reflection can occur at action, task, plan, or goal level.
Deterministic validation should be preferred where possible.
Model-based reflection is useful when evaluation requires interpretation or adaptive judgment.
Self-correction can involve retry, modified inputs, alternative tools, additional retrieval, re-planning, clarification, or escalation.
Reflection should measure whether corrective actions actually improve the outcome.
Reflection loops must be bounded to prevent infinite execution.
Risk-based reflection allows stronger controls for high-impact operations.
Reflection must never bypass enterprise security and authorization boundaries.
Reflection events should be observable and measurable.
Human escalation provides a safe boundary when autonomous recovery is unsuccessful.
The goal is not maximum self-correction.
The goal is reliable, controlled, and measurable recovery.

Previous¶

09. Agent Reasoning

Next¶

02. Agent Memory

Enterprise AI Engineering Handbook
Building Production-Grade Enterprise AI Systems — One Chapter at a Time.

Reflection & Self-Correction in AI Agents¶

📖 Overview¶

🎯 Learning Objectives¶

1. What Is Reflection?¶

2. What Is Self-Correction?¶

3. Why Do Agents Need Reflection?¶

4. Reflection in the Agent Loop¶

5. Reflection vs Reasoning¶

Reasoning¶

Reflection¶

6. Reflection vs Planning¶

7. Reflection vs Retry¶

Retry¶

Self-Correction¶

8. Reflection vs Error Handling¶

9. What Can an Agent Reflect On?¶

Action-Level Reflection¶

Tool-Level Reflection¶

Task-Level Reflection¶

Plan-Level Reflection¶

Goal-Level Reflection¶

10. Outcome Validation¶

11. Reflection Criteria¶

12. Critique-Based Reflection¶

13. Critique → Correction Loop¶

14. Self-Correction Through Re-Planning¶

15. Reflection with Tool Results¶

16. Reflection with Structured Outputs¶

17. Reflection with Memory¶

18. Reflection and Agent State¶

19. Reflection Granularity¶

Per Action¶

Per Task¶

Per Plan¶

Final Outcome¶

20. Adaptive Reflection¶

21. Reflection and Guardrails¶

22. Reflection and Human Escalation¶

23. Correction Strategies¶

Retry¶

Modify Input¶

Use Alternative Tool¶

Retrieve More Information¶

Re-plan¶

Ask User¶

Escalate¶

24. Self-Correction Decision Tree¶

25. Reflection Loops¶

26. Avoiding Infinite Self-Correction¶

27. Progress Detection¶

28. Reflection Cost¶

29. Reflection vs Deterministic Validation¶

30. Hybrid Self-Correction Architecture¶

31. Reflection Observability¶

32. Reflection Metrics¶

33. Reflection Evaluation¶

34. Practical Example — Customer Support Agent¶

35. Practical Example — Software Engineering Agent¶

36. Practical Example — RAG Agent¶

37. Reflection and Agent Memory¶

38. Reflection and Security¶

39. Reflection and Human-in-the-Loop¶

40. Enterprise Reflection Architecture¶

41. Reflection Lifecycle¶

42. Production Guardrails¶

43. Key Engineering Principles¶

1. Reflection Must Have a Purpose¶

2. Validate Before Reflecting¶

3. Separate Retry from Correction¶

4. Re-Plan When the Strategy Is Invalid¶

5. Use Risk-Based Reflection¶

6. Bound Reflection Loops¶

7. Measure Improvement¶

8. Preserve Security Boundaries¶

9. Observe Recovery¶

10. Escalate When Necessary¶

44. Reflection Architecture Pattern¶

45. Part VI → Part VII Boundary¶

📌 Key Takeaways¶

🔗 Related Topics¶