Reflection vs Reflexion vs ReAct: Which Pattern to Use?
When developers start building agentic AI systems with LangChain or LangGraph, three terms appear repeatedly:
- Reflection
- Reflexion
- ReAct
They sound similar because all three involve an LLM doing more than a single generation. But architecturally, they solve different problems.
A common mistake is to think:
"ReAct, Reflection and Reflexion are three names for the same type of agent."
They are not.
The better mental model is:
- ReAct → How should the agent reason and use tools?
- Reflection → How should the agent review and improve its output?
- Reflexion → How should the agent use feedback/evidence from previous attempts to improve subsequent attempts?
Reflection is typically framed as a generator → reflector loop, while Reflexion extends this with external tools, structured outputs, citations and iterative revision. The original ReAct paper (Yao et al., 2023) combines reasoning traces with task-specific actions so the model can interact with external sources or environments and update its plan based on observations.
This distinction becomes extremely important when designing production AI/ML systems.
1. The Short Answer
If you only remember one table from this article, remember this:
| Pattern Primary Question Main Capability Best For | |||
|---|---|---|---|
| ReAct | "What should I do next?" | Reason + Act | Tool-using agents |
| Reflection | "Is my answer good?" | Critique + Revise | Content/code improvement |
| Reflexion | "What did I learn from this attempt and what evidence can improve the next one?" | Feedback + Evidence + Revision | Complex iterative agents |
A simplified architecture:
REACT
User → Reason → Tool → Observation → Reason → Tool → Answer
REFLECTION
User → Generate → Critique → Revise → Critique → Answer
REFLEXION
User → Generate
↓
Critique
↓
Missing information
↓
Tools/Search
↓
Evidence
↓
Revisor
↓
Evaluate / Continue
↓
Final Answer
2. Why Do We Need Three Patterns?
A basic LLM application looks like this:
User → LLM → Answer
This is fine for:
- "What is Python?"
- "Explain REST API."
- "Write a welcome message."
But production AI systems are different. Consider:
"Investigate why our payment API started returning HTTP 500 errors after today's deployment and recommend the safest fix."
A single LLM call may not have enough information. It needs to inspect logs, inspect deployment changes, inspect database state, reason about possible causes, compare evidence, evaluate its initial diagnosis, and revise the conclusion.
Now we have multiple architectural choices.
3. ReAct: The Agent That Acts
ReAct stands for Reasoning + Acting. The original ReAct paper describes an approach where language models interleave reasoning traces with actions, allowing them to interact with external sources and environments.
The practical loop looks like:
Thought → Action → Action Input → Observation → Thought → Action → Observation → Final Answer
The important point is: ReAct is primarily about deciding what action to take next based on observations.
4. ReAct Example
Suppose a user asks:
"What's the weather in Tokyo and what should I wear?"
The agent doesn't know the current weather, so:
User
↓
LLM
↓
Thought: I need current Tokyo weather.
↓
Action: weather_search
↓
Action Input: Tokyo weather
↓
Observation: 22°C, sunny
↓
LLM
↓
Thought: Now I need a clothing recommendation.
↓
Action: clothing_tool
↓
Action Input: 22°C, sunny
↓
Observation: Light clothing recommended
↓
Final Answer
The agent is not primarily criticizing itself. It is interacting with an environment.
5. ReAct in LangGraph
Conceptually:
START
↓
Agent
↓
Tools?
├── YES → ToolNode → Agent
└── NO → END
A simplified implementation can look like:
from langchain.agents import create_agent
agent = create_agent(
model="openai:gpt-4o", # use whichever model string your provider supports
tools=[search_tool, database_tool]
)
Current LangChain documentation describes an agent as a model calling tools in a loop until the task is complete, with the surrounding "harness" controlling the model, prompt, tools and middleware. LangGraph's reference also exposes tool-loop functionality and conditional routing for tool-calling workflows.
6. Reflection: The Agent That Reviews
Now consider a different problem.
"Write a technical LinkedIn post explaining RAG."
The LLM can generate a post immediately. But we want another LLM role to ask:
- Is the post technically accurate?
- Is it too generic?
- Is the explanation understandable?
- Are important concepts missing?
- Is anything unnecessary?
That gives:
Generator → Reflector → Generator → Reflector → Final
This is exactly the generator/reflector architecture commonly demonstrated with LinkedIn-post or essay-optimization workflows.
7. Reflection Example
Initial answer:
RAG is a technique where an LLM searches a database before generating an answer.
Reflector — problems:
- "Database" is too broad.
- It doesn't explain retrieval.
- It doesn't distinguish vector search from generation.
- It doesn't explain why RAG reduces unsupported answers.
Generator — revised:
Retrieval-Augmented Generation (RAG) combines information retrieval with language generation. Instead of relying only on the model's parametric knowledge, the application retrieves relevant documents and provides them as context to the LLM before generating the answer.
Now we have:
Generate → Critique → Improve
That's Reflection.
8. The Core Difference: ReAct vs Reflection
This is the first distinction every AI engineer should understand.
- ReAct asks: "What should I do next?" → Action-oriented
- Reflection asks: "How good is what I just produced?" → Quality-oriented
ReAct
I need information → Search → I found information → Query database → I found more information → Answer
Reflection
I generated an answer → The answer is incomplete → Improve it → The new answer is better
9. Reflexion: Reflection + Feedback + External Evidence
Now we reach the most interesting pattern. Reflexion builds on reflection by adding:
- external tools
- current information
- citations
- structured outputs
- iterative revision
- previous outputs passed through the workflow
So:
Reflection = Generate → Critique → Revise
Reflexion = Generate
→ Critique
→ Identify missing information
→ Use tools
→ Gather evidence
→ Revise
→ Critique again
→ Repeat
This is a much more powerful — and more expensive — architecture.
10. The Original Reflexion Idea
The original Reflexion paper (Shinn et al., 2023) describes Reflexion as a framework where agents verbally reflect on task feedback signals, then maintain their own reflective text in an episodic memory buffer to induce better decision-making in subsequent trials. Reflexion reinforces language agents not by updating model weights, but through linguistic feedback.
This is an important point. When we say "Reflexion is self-improvement," we should not automatically interpret that as LLM weights are being retrained. Instead, the idea is closer to:
Attempt → Feedback → Reflection → Store useful feedback → Next attempt uses feedback
That is runtime / linguistic self-improvement, not model fine-tuning.
11. Three Patterns as Questions
An easy way to remember them:
USER
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
REACT REFLECTION REFLEXION
"What "Is this "What did I
should good?" learn and
I do?" what evidence
can improve it?"
This mental model is more useful than memorizing definitions.
12. One Project — Three Architectures
Let's use the same project to understand all three.
Project: Build an AI Production Incident Investigator.
Technology: FastAPI, PostgreSQL, Redis, Kubernetes, GitHub, Sentry, Prometheus, LangGraph, LLM.
User asks: "Why did the payment API start returning 500 errors after deployment?"
Let's implement the same requirement using all three patterns.
13. Version 1 — ReAct Incident Agent
User → ReAct Agent → Get Logs → Observation → Check Deployment → Observation → Check Database → Observation → Answer
The agent might reason: "I need logs first."
Tool: get_logs("payment-api") Observation: SQLAlchemy OperationalError: connection pool exhausted
"I should inspect deployment configuration."
Tool: get_deployment_diff("payment-api") Observation: Database pool configuration changed.
"I should verify PostgreSQL connection usage."
Tool: get_db_metrics() Observation: 95/100 connections used.
Final: Likely root cause: database connection pool exhaustion caused by the recent deployment configuration change.
This is a very good use case for ReAct — the agent dynamically decides which tool to call next.
14. Version 2 — Reflection Incident Agent
Now imagine we don't need many tools. We already have logs, deployment diff, and database metrics available as input. The problem is that the first diagnosis might be incomplete.
Incident Data → Generator → Initial Diagnosis → Reflector → Missing Evidence? → Generator → Final Diagnosis
Initial: "The database connection pool is exhausted."
Reflector: The diagnosis identifies the immediate failure, but does not establish whether the deployment caused it. Missing: deployment configuration comparison, connection limit, historical connection usage.
Generator (revised): The immediate failure is connection pool exhaustion. The deployment is a likely contributing factor because the connection pool configuration changed. The database metrics show 95/100 connections in use, supporting the hypothesis.
Here, Reflection works well.
15. Version 3 — Reflexion Incident Agent
Now combine both:
User
↓
Responder
↓
Critique
↓
What is missing?
↓
Tool Planner
↓
┌──────────┼──────────┐
↓ ↓ ↓
Logs GitHub DB
└──────────┼──────────┘
↓
Evidence
↓
Revisor
↓
Evaluator
↓
Continue?
↙ ↘
YES NO
↓ ↓
Tools Final
Now the system doesn't merely use tools — it uses feedback to decide what information it needs and how the next answer should change. That's where Reflexion becomes valuable.
16. ReAct vs Reflexion in the Same Example
Imagine the initial diagnosis is: "Database connectivity is the problem."
ReAct: "I need evidence → Call logs → I need deployment information → Call GitHub → I need database metrics → Call monitoring." The focus is: what action should I take next?
Reflexion: "My diagnosis is too broad. I haven't established whether the deployment caused the failure. I need: deployment diff, connection metrics, previous configuration." Then it retrieves that evidence. The focus is: what is wrong with my current conclusion, and what evidence can fix it?
17. Reflection vs Reflexion: The "X" Matters
Reflexion goes beyond reflection by producing responses that incorporate current information, citations and verifiable claims rather than simply generating improved opinions.
Reflection → Better answer
Reflexion → Better + evidence-backed answer
This is especially important for research, technical analysis, production debugging, compliance, data analysis, enterprise knowledge, and high-value decision support.
18. Where ReAct Is Better
Use ReAct when the primary challenge is interaction with tools or an environment.
Travel Agent: Search flights → Check hotel → Check weather → Calculate itinerary → Answer
Database Agent: Inspect schema → Generate SQL → Execute SQL → Inspect result → Generate next query
Coding Agent: Inspect repository → Read file → Modify code → Run tests → Inspect failure → Modify code
Customer Support: Get account → Check order → Check refund policy → Create ticket
The core requirement: the agent must decide what action/tool to take next.
19. Where Reflection Is Better
Use Reflection when the primary problem is output quality.
Content Generation: Generate article → Critique → Improve
Code Generation: Generate implementation → Review code → Improve implementation
Documentation: Generate API documentation → Technical review → Improve documentation
Interview Answer: Generate answer → Interviewer's critique → Improve answer
You don't necessarily need web search or multiple external tools. The core requirement: improve an existing output.
20. Where Reflexion Is Better
Use Reflexion when all three matter: complex task + feedback + external evidence.
Research Agent: Draft research → Identify unsupported claims → Search papers → Revise → Check citations → Repeat
Production Incident Agent: Initial diagnosis → Identify uncertainty → Inspect logs → Inspect deployment → Revise diagnosis → Validate
Security Analysis: Initial finding → Critique → Check CVE/database → Inspect code → Revise severity → Validate
Data Science Agent: Hypothesis → Analyze data → Find contradiction → Run another analysis → Revise hypothesis
21. The Patterns Can Be Combined
This is where experienced developers should move beyond textbook definitions. You don't have to choose only one. A production agent can use:
Reflexion
│
▼
ReAct
│
┌─────────┼─────────┐
▼ ▼ ▼
RAG APIs Tools
│ │ │
└─────────┼─────────┘
▼
Reflection
│
▼
Revisor
For example: Reflexion Controller → ReAct Tool Loop → External Evidence → Reflection → Revision → Evaluation.
This is often more realistic than implementing a pure textbook pattern.
22. A Production Architecture
For an enterprise AI application, a reasonable design looks like this:
User
│
▼
┌────────────────┐
│ Task Classifier│
└───────┬────────┘
│
┌───────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Simple ReAct Reflexion
Task Agent Agent
│ │ │
│ ┌─────┴─────┐ │
│ │ │ │
│ Tools Observation │
│ │ │ │
│ └─────┬─────┘ │
│ │ │
│ ▼ │
│ Reflection ◄─────────┘
│ │
└───────────────┼────────────────┘
▼
Evaluator
│
▼
Answer
The first important engineering decision is therefore not "Should I use ReAct or Reflexion?" It is: what problem does this agent actually need to solve?
23. Decision Framework
Does the task require external tools?
│
NO
│
▼
Does the output need iterative improvement?
│
YES
│
▼
Reflection
Does the task require tools?
│
YES
│
▼
Does the agent dynamically decide
which tool/action to take?
│
YES
│
▼
ReAct
Does the system need to critique
previous attempts and use evidence
to improve subsequent attempts?
│
YES
│
▼
Reflexion
24. A Practical Comparison
Relative architectural complexity — illustrative engineering comparison, not benchmark performance. Higher generally means more orchestration components and runtime control are typically required: ReAct is lowest, Reflection is moderate, Reflexion is highest. Reflexion generally introduces more workflow state, evaluation, evidence handling and iteration control than a basic ReAct loop.
25. Cost and Latency Matter
This is where a real software engineer thinks differently from a demo builder. Illustrative call counts:
- Simple LLM: 1 model call
- ReAct: 3 model calls + 3 tool calls
- Reflection: 3 model calls
- Reflexion: 5 model calls + 4 tool calls + evaluator
These numbers are illustrative, but the engineering trade-off is real: more reasoning → more calls → more latency → more token usage → higher cost.
Don't use Reflexion simply because it is more advanced. Use it when the additional quality justifies the cost.
26. A Simple Cost Model
total_cost = (
llm_input_tokens * input_price
+ llm_output_tokens * output_price
+ tool_calls * tool_cost
)
latency ≈ model_latency + tool_latency + orchestration_overhead
For a production system, track: average\_iterations, p95\_latency, token\_usage, tool\_calls, failure\_rate, answer\_quality, cost\_per\_task. Then compare ReAct vs Reflection vs Reflexion using your actual workload.
27. A Very Important Point: More Iterations ≠ Better
A common beginner mistake: "Let's run Reflexion 10 times. The answer will be much better." Not necessarily.
Iteration 1 — Good answer
Iteration 2 — Better answer
Iteration 3 — Slightly better
Iteration 4 — Unnecessary changes
Iteration 5 — Introduces an error
Therefore, use a quality gate:
Revisor → Evaluator →
┌────────┴────────┐
│ │
Good enough Not enough
│ │
END More tools
28. Reflection Should Be Structured
Schema-based outputs let the system distinguish response, reflection, missing, superfluous, and search_queries — instead of receiving an unstructured block of text.
from pydantic import BaseModel
class Reflection(BaseModel):
missing: list[str]
superfluous: list[str]
class AnswerQuestion(BaseModel):
answer: str
reflection: Reflection
search_queries: list[str]
This is important because the graph can now programmatically decide:
if response.reflection.missing:
call_tools()
rather than asking another LLM to interpret free-form text.
29. ReAct Also Benefits From Structured Tool Calls
ReAct shouldn't mean:
Thought: I think maybe search something...
Action: probably search...
Action Input: something about the issue...
Modern agent frameworks represent tool calls structurally. Current LangChain documentation describes tools as Python callables, LangChain tools, or tool definitions passed to an agent, with the agent looping over model/tool interactions. This makes production implementation much cleaner.
30. LangGraph's Role
LangGraph is not Reflection or ReAct itself. LangGraph is the orchestration infrastructure.
Current LangGraph documentation describes it as a low-level framework for building long-running, stateful agents, particularly when you need durable execution, persistence, human-in-the-loop, streaming, memory and controlled workflows.
ReAct = Agent behavior pattern
Reflection = Quality-improvement pattern
Reflexion = Feedback-driven improvement pattern
LangGraph = Workflow/orchestration infrastructure
That's a very important architectural distinction.
31. LangGraph Can Implement All Three
ReAct
START → Agent → Tools?
├── YES → Tool → Agent
└── NO → END
Reflection
START → Generator → Reflector → Generator → END
Reflexion
START → Responder → Reflection → Tool → Revisor → Evaluator → Continue?
├── YES → Tool/Revisor
└── NO → END
This is why learning LangGraph is valuable: it gives you a common orchestration layer for different agent patterns.
32. The Same Tool Can Exist in All Three
@tool
def search_docs(query: str):
...
- ReAct: the agent decides — "I need documentation" → search\_docs()
- Reflection: the reflector says — "The answer is missing official documentation" → search\_docs()
- Reflexion: the revisor identifies — "Claim X is unsupported, need official documentation" → search\_docs() → evaluate result → revise claim
Same tool. Different orchestration pattern.
33. RAG + ReAct + Reflexion
This combination is particularly powerful. Imagine an enterprise coding assistant:
User
↓
Reflexion
↓
ReAct
↓
┌──────┼──────┐
↓ ↓ ↓
RAG GitHub Tests
│ │ │
└──────┼──────┘
↓
Evidence
↓
Revisor
↓
Evaluator
↓
Answer
Example: "Why does our authentication service fail intermittently?" The agent could search internal documentation using RAG, inspect GitHub changes, read logs, run tests, compare the initial hypothesis with evidence, revise the diagnosis, run another validation, and return a grounded answer. This is a realistic enterprise agent architecture.
34. What About Memory?
Reflection does not automatically mean persistent memory. Similarly, ReAct does not automatically mean long-term memory. Reflexion, in its original formulation, explicitly uses reflective text in an episodic memory buffer to influence later trials.
Modern LangGraph/LangMem tooling also supports persistent memory patterns, including DB-backed storage for production use.
Conversation State ≠ Long-Term Memory ≠ Model Training
These are three different concepts.
35. Example: Coding Agent
ReAct Coding Agent
User: Fix failing authentication test.
Agent: Inspect repository → read_file() → Observation: AuthService.py
Agent: Inspect test → read_file() → Observation: test_auth.py
Agent: Modify implementation → apply_patch() → Observation: Patch applied.
Agent: Run tests → pytest() → Observation: 2 failures.
Agent: Fix again → apply_patch() → pytest() → Observation: All tests passed.
Final.
This is fundamentally ReAct.
36. Reflection Coding Agent
Generate implementation → Code Reviewer → "Missing error handling" → Generate revised implementation → Code Reviewer → "Looks good" → Final
This is Reflection.
37. Reflexion Coding Agent
Generate code → Run tests → Test failures → Reflection → What went wrong? → Search documentation → Inspect repository → Revise code → Run tests → Evaluator → Pass?
This is much closer to Reflexion + ReAct combined.
Notice the important insight: production agents are often combinations of patterns, not pure implementations of one pattern.
38. Which Pattern Should You Learn First?
For an AI/ML engineer, a reasonable progression:
1. Basic LLM
2. Tool Calling
3. ReAct
4. Structured Output
5. Reflection
6. Reflexion
7. RAG + Agents
8. Evaluation
9. Production LangGraph
Each stage solves another problem: LLM → Generate; Tool Calling → Interact; ReAct → Decide actions; Reflection → Improve output; Reflexion → Improve using feedback/evidence; Evaluation → Measure improvement; LangGraph → Orchestrate the complete system.
39. Interview-Level Answer
If an interviewer asks: "What is the difference between ReAct, Reflection and Reflexion?"
A strong answer: ReAct is primarily an action-oriented agent pattern where the model interleaves reasoning with tool or environment interactions and uses observations to decide what to do next. Reflection is an iterative quality-improvement pattern where a generator produces an output and a reflector critiques it before another generation. Reflexion extends the reflection idea by using feedback from previous attempts, external tools or environments, structured information and, in the original formulation, reflective episodic memory to improve subsequent behavior. In LangGraph, all three can be implemented as graph workflows using nodes, state, tool execution and conditional edges.
That answer shows architectural understanding rather than memorization.
40. The Most Important Production Decision
When designing an agent, ask these five questions:
- Does the agent need tools? NO → LLM/Reflection · YES → ReAct or Reflexion
- Does it need to dynamically decide which tool to call? YES → ReAct
- Does the generated output need iterative review? YES → Reflection
- Does the review require external evidence? YES → Reflexion
- Are mistakes expensive enough to justify extra latency/cost? NO → keep it simple. YES → consider Reflexion/evaluation.
41. The Final Mental Model
Don't remember three complicated definitions. Remember three verbs:
REACT → ACT
REFLECTION → REVIEW
REFLEXION → LEARN FROM FEEDBACK
Or, even better:
Agent Design
What is needed?
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
ACTION QUALITY FEEDBACK
│ │ │
▼ ▼ ▼
ReAct Reflection Reflexion
And in real projects:
Production Agent
│
▼
Reflexion
│
▼
ReAct
│
┌──────────┼──────────┐
▼ ▼ ▼
RAG APIs Tools
└──────────┼──────────┘
▼
Reflection
│
▼
Revisor
│
▼
Evaluator
│
▼
Final Answer
That is the level at which an experienced AI/ML engineer should think about these patterns.
42. Conclusion
ReAct, Reflection and Reflexion are not competing buzzwords. They address different dimensions of agent behavior.
ReAct is about acting intelligently in an environment: Reason → Act → Observe → Reason. The original ReAct research demonstrated the benefit of interleaving reasoning with actions that retrieve information from external sources or interact with environments.
Reflection is about reviewing and improving generated work: Generate → Critique → Revise, using generator and reflector roles to demonstrate iterative improvement.
Reflexion goes further by making feedback, external information, structured outputs and previous attempts part of an iterative improvement process — using responder/revisor nodes, tool outputs, citations and a repeated feedback cycle. The original Reflexion research frames this as verbal reinforcement using reflective feedback rather than updating model weights.
And LangGraph is the orchestration layer that lets you turn these ideas into controlled, stateful workflows with tools, routing, persistence and iteration.
The rule to use in a real project:
Need to DO something? → ReAct
Need to IMPROVE something? → Reflection
Need to IMPROVE something USING
FEEDBACK + EVIDENCE ACROSS
ITERATIONS? → Reflexion
And for a serious enterprise AI system:
ReAct + Reflection + Reflexion + RAG + Structured Outputs + Evaluation + LangGraph
is often a more useful way to think than trying to select only one pattern.
That is the transition from "building an LLM demo" to "engineering an agentic AI system."
References
- Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arxiv.org/abs/2210.03629
- Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. arxiv.org/abs/2303.11366
- LangChain Agents documentation — current agent/tool-loop architecture.
- LangGraph official documentation — orchestration, stateful agents and production workflows.
0 Comments