Module 5: Multi-Step Reasoning and Planning

1. Introduction: Agents That Think Before They Act

Description

Module 4 solved a real problem: your agent stopped being linear. With StateGraph you gave it cycles, branching, stop conditions — explicit control over how execution flows. The Research Agent has 4 nodes (planning, research, analysis, synthesis), conditional routing that decides when to re-iterate, and iteration limits that prevent infinite loops. It's a controlled agent. But there's a problem that flow control doesn't solve: your agent reacts to every input without thinking about the overall strategy. It gets a question, searches for the first thing that comes to mind, analyzes what it found, and synthesizes. If the first search wasn't good, conditional routing sends it back — but not because the agent thought it needed a different strategy, rather because a numeric threshold fired. The state machine controls the flow; nobody controls the intelligence of the decisions inside that flow.

This module adds the missing layer: thinking before acting. An agent with a state machine and no planning is like a worker with tools but no plan — it executes tasks mechanically, but it doesn't break a complex problem into manageable parts, doesn't evaluate whether its own work is good, and doesn't adjust its strategy when something fails. The difference between "I search for the first thing that comes to mind" and "first I decompose the task, then I execute each step, and at the end I evaluate whether the result holds up" is the difference between a reactive agent and a deliberative one. In production, that difference is measurable: tasks solved with 2 useless tool calls vs 8 precise ones, fragmented results vs coherent reports, agents that confidently deliver garbage vs agents that catch their own mistakes and correct them.

Three capabilities define this module: planning (decompose before acting), reflection (evaluate your own output and decide whether to correct it), and reasoning traces (make the agent's thinking visible and debuggable). These aren't academic concepts — they're implementation patterns with code, measurable trade-offs, and known failure modes. Together, they turn the Research Agent from something that follows a graph reactively into something that deliberates: it plans its research, executes the plan, reflects on the quality of the result, and re-plans if it finds gaps. The tone of this module is analytical: this isn't about evangelizing a pattern, it's about giving you data to decide when planning justifies its cost and when reflection is worth the extra latency.

Where Are We in the Guide?

Context

This guide has 10 modules organized into 3 phases:

Phase 1: Agent Foundations (Modules 1-3)          ✓ COMPLETED
├── Module 01: Anatomy of an AI Agent             ✓ COMPLETED
├── Module 02: Tool Use Fundamentals              ✓ COMPLETED
└── Module 03: Function Calling Patterns          ✓ COMPLETED

Phase 2: Agent Architecture (Modules 4-7)         ← YOU ARE HERE
├── Module 04: State Machines for Agents          ✓ COMPLETED
├── Module 05: Multi-Step Reasoning and Planning  ← THIS MODULE
├── Module 06: Memory Systems for Agents
└── Module 07: MCP and Advanced Tool Integration

Phase 3: Multi-Agent & Production (Modules 8-10)
├── Module 08: Multi-Agent Orchestration
├── Module 09: Testing and Evaluating Agents
└── Module 10: Agents in Production and Alternatives

Second module of Phase 2. Module 4 gave you the architecture — your agent is a StateGraph with nodes, edges, and conditional routing. Now you give intelligence to the decisions inside that architecture. The Phase 2 progression is still deliberate:

Module 4 — How you control the flow → State machines: cycles, branching, stop conditions ✓
Module 5 — How it reasons deeply → Planning, reflection, self-correction ← HERE
Module 6 — How it remembers → Short-term, long-term, checkpointing, durable execution
Module 7 — How it connects to the world → MCP servers, clients, dynamic tools, ecosystem

Where are you coming from?

Module 4 left you with a working Research Agent:

Custom StateGraph: 4 nodes (planning, research, analysis, synthesis) connected by explicit edges
Extensible typed state: AgentState with messages, current_plan, iteration_count, tool_results, quality_score, budget_remaining, metadata — designed to grow
Cyclic agent loops: The research→analysis→conditional check cycle that goes back to planning when the information is insufficient, bounded by stop conditions
Conditional routing: Deterministic decision points based on state — not on the model's free choice
Functional API: You know when @entrypoint/@task is more natural than StateGraph for certain patterns
Modular subgraphs: Capabilities encapsulated with clear interfaces, the foundation for multi-agent in M8

That's a controlled agent. But not an agent that's intelligent in its decisions. The M4 "planning" node is a placeholder: it generates a simple plan with no real decomposition. The agent doesn't evaluate whether its output is good — the conditional check measures a threshold, not semantic quality. And when something fails, the agent re-iterates mechanically instead of diagnosing what failed and how to change the strategy.

Where are you going?

The M4 → M5 transition is direct: "Your agent has a state machine that controls the flow → now make the decisions inside that flow intelligent." M4 controls how execution flows. M5 controls what the agent decides to do at each step.

After M5, Module 6 solves a problem that emerges naturally from planning: plans need to persist. If your agent crashes halfway through a 10-step investigation, without memory it loses all progress. M5 plans and reflects; M6 makes those plans and reflections survive across sessions.

From Reactive to Deliberative

The limit of a reactive agent

A reactive agent responds directly to every input. It gets a question, acts, delivers a result. If the result isn't enough, it iterates — but without a different strategy. It's the equivalent of an employee who, given the instruction "research the AI market," opens Google, searches "AI market," reads the first result, and summarizes it for you. If you say "I need more," they repeat exactly the same thing with slightly different synonyms.

The M4 Research Agent works like this. Yes, it has a state machine that gives it cycles and branching. But look at the difference:

REACTIVE AGENT (M4):
  User: "Research the impact of LLMs on healthcare"
  → Planning: "Search LLMs healthcare" (one step, no decomposition)
  → Research: searches "LLMs healthcare", gets 3 results
  → Analysis: evaluates whether the results are relevant (numeric threshold)
  → Conditional: quality_score < 0.7 → back to planning
  → Planning: "Search LLMs healthcare applications" (basically the same thing)
  → Research: searches again, similar results
  → ... repeats until max_iterations

The agent has the mechanism to re-iterate, but not the intelligence to do it differently each time. The state machine is the skeleton; it's missing the brain.

The shift to deliberative

A deliberative agent thinks before acting, evaluates after acting, and adjusts its strategy based on what it learned:

DELIBERATIVE AGENT (M5):
  User: "Research the impact of LLMs on healthcare"
  → Planning: decomposes into sub-questions:
      1. "What LLM applications exist in healthcare today?"
      2. "What are the measurable results (papers, studies)?"
      3. "What risks and limitations have been documented?"
      4. "What regulations apply?"
  → Research: runs each sub-question as an independent search
  → Analysis: combines results, detects gaps
  → Reflection: "I have good coverage of applications and results,
     but sub-questions 3 and 4 have few reliable sources.
     Also, I didn't find the perspective of medical professionals."
  → Re-planning: generates new sub-questions for the gaps:
      3b. "Risks of LLMs in medical diagnosis — 2024-2025 studies"
      5. "Doctors' perspective on AI use in clinical practice"
  → Research: runs only the new sub-questions
  → Reflection: "Now coverage is complete. quality_score: 0.85"
  → Synthesis: produces the final report

The difference isn't just "more steps" — it's steps with a purpose. Each iteration adds new information because the agent diagnosed what was missing. Re-planning doesn't repeat the same search: it generates different questions based on an analysis of what it already found.

Three new operations in the graph

The transition from reactive to deliberative is implemented as three new operations in your StateGraph:

Operation	What it does	Where in the graph
Planning	Decomposes the task into sub-tasks before executing	Expanded node: from "generate a simple plan" to "decompose, prioritize, and build a dependency graph"
Reflection	Evaluates the quality of the output with critique prompts	New node after analysis: evaluates completeness, accuracy, gaps
Re-planning	Generates an alternative plan based on the reflection	Conditional edge: if reflection detects gaps → a new plan that covers them

These three operations slot into the M4 state machine without rewriting it. The existing graph gains nodes and edges — it isn't replaced. That's the payoff of having designed an extensible state in M4.

The Three Pillars: Planning, Reflection, Reasoning Traces

Pillar 1: Planning — Decompose before acting

Planning is an agent's ability to take a complex task and turn it into a sequence of manageable sub-tasks before executing anything. It isn't a generic "make a plan" prompt — it's a structured process:

Task decomposition: The original task is broken into sub-tasks with explicit dependencies
Prioritization: Sub-tasks are ordered by importance and dependency
Plan as an artifact: The plan is stored in the state as a structured object, not as free text

# The plan as an artifact in the state — not free text, but structure
plan = {
    "goal": "Research the impact of LLMs on healthcare",
    "subtasks": [
        {"id": 1, "query": "Current applications of LLMs in healthcare", "status": "pending", "depends_on": []},
        {"id": 2, "query": "Measurable results and studies", "status": "pending", "depends_on": [1]},
        {"id": 3, "query": "Documented risks and limitations", "status": "pending", "depends_on": []},
        {"id": 4, "query": "Applicable regulatory framework", "status": "pending", "depends_on": [3]},
    ]
}

Why structure and not free text? Because a structured plan is iterable (you can run sub-tasks in order), trackable (you know which ones you completed), and debuggable (you can see exactly where it failed). A free-text plan is opaque.

This module covers two planning patterns: ReAct (the agent thinks and acts in an interleaved way — Thought→Action→Observation at each step) and Plan-and-Execute (the agent plans everything first, then executes the full plan, then evaluates). They aren't mutually exclusive — you can combine them. But they have very different trade-offs, and this module quantifies them.

Pillar 2: Reflection — Evaluate your own output

Reflection is the agent's ability to be its own critic. After producing a result, the agent evaluates it against specific criteria and decides whether to deliver it or improve it. It isn't a generic "is this okay?" — they're concrete questions:

"Does the answer address the original question directly?"
"Are there claims with no source backing them?"
"Are there contradictions between the cited sources?"
"Are there obvious gaps the user would expect covered?"
"Is the level of detail proportional to the complexity of the question?"

The implementation is a node in the graph with a specialized critique prompt. The model evaluates its own output (or the output of a previous step) and produces a structured judgment:

reflection = {
    "quality_score": 0.72,
    "gaps": ["European regulations were not covered", "2025 data is missing"],
    "contradictions": [],
    "recommendation": "re-plan",  # "deliver" | "re-plan" | "refine"
    "notes": "Good coverage of applications but weak on the legal framework"
}

That recommendation feeds a conditional edge: if it's "deliver", the agent moves on to synthesis. If it's "re-plan", it generates a new plan covering the detected gaps. If it's "refine", it rewrites the current output without new information.

The main risk of reflection is the infinite reflection loop: the agent corrects itself, reflects, finds one more thing to correct, corrects itself, reflects — until the budget is gone. Guardrails are mandatory: max_reflection_iterations, quality thresholds with tolerance, and a fallback that says "deliver what you have if you've already iterated N times."

Pillar 3: Reasoning Traces — Visible thinking

Reasoning traces are the record of the agent's thinking: what it considered, what it discarded, why it made each decision. They aren't generic logs — they're the reasoning process captured as structured data.

Why do they matter? Because when an agent fails, the critical question is why. Without reasoning traces, all you see is input and output — a black box. With reasoning traces, you can trace:

"The planner generated 4 sub-questions, but sub-question 3 was too broad"
"The search for sub-question 2 returned 0 results because it used an overly specific term"
"Reflection detected the gap but the re-planning didn't address it correctly"

That's debugging the reasoning, not just debugging the code. In production, reasoning traces let you:

Debugging: Identify where the agent's logic failed, not just that it failed
Observability: Monitor the quality of the reasoning in real time
Explainability: Show the user why the agent reached its conclusion
Evaluation: Build datasets of trajectories to evaluate whether the agent "reasons well"

Capturing reasoning traces doesn't require complex infrastructure — they're extra fields in the state plus structured logging in each node. Module 9 (Testing) uses these traces for trajectory evaluation. Module 10 (Production) integrates them with LangSmith for observability.

The Cost of Thinking

Planning and reflection aren't free

Every "thinking" operation is an additional LLM call. An agent that plans and reflects makes more calls than one that acts directly. That has a concrete cost along three dimensions:

Metric	Without planning/reflection	With planning/reflection	Delta
LLM calls	3-4 per task	7-12 per task	+100-200%
Latency	4-6 seconds	10-18 seconds	+150-200%
Cost (tokens)	~2,000-3,000 tokens	~6,000-12,000 tokens	+200-300%
Result quality	Variable, frequent gaps	Consistent, gaps detected	+30-50% improvement

These numbers are representative for a medium-complexity research task with GPT-4.1-mini. They vary with the model, the complexity of the task, and the guardrail configuration.

When the cost is justified

Not every task needs planning and reflection. The practical rule:

Planning justifies its cost when:

The task has multiple aspects to investigate (not a simple question)
Execution order matters (there are dependencies between sub-tasks)
Failing on one aspect invalidates the whole result
The user expects thoroughness, not speed

Reflection justifies its cost when:

Quality of the result matters more than speed
There are objective, evaluable quality criteria (completeness, accuracy, sourcing)
The cost of delivering a bad result is high (business decisions, publications, legal analysis)
There's a feedback loop: the agent can genuinely improve if it detects problems

Neither planning nor reflection is justified when:

The task is simple and direct ("What's the capital of France?")
Latency is the absolute priority (real-time support chatbots)
The model produces good results in a single step for that kind of input
The token budget is very limited

The decision function in production

In a real system, you don't hardcode "always plan" or "never reflect." You implement a decision function that evaluates the complexity of each input and turns on the appropriate capabilities:

def should_plan(query: str, context: dict) -> bool:
    complexity = estimate_complexity(query)
    budget = context.get("budget_remaining", float("inf"))
    if complexity == "simple" or budget < MIN_PLANNING_BUDGET:
        return False
    return True

def should_reflect(result: dict, context: dict) -> bool:
    stakes = context.get("stakes", "normal")
    iterations = context.get("reflection_iterations", 0)
    if stakes == "low" or iterations >= MAX_REFLECTION_ITERATIONS:
        return False
    return True

This module gives you the patterns and the data to build that decision function. It isn't about "always think more" — it's about thinking when it's worth it.

Prerequisites

From Module 4 (State Machines for Agents)

This module takes the M4 Research Agent directly and extends it. You need these to be solid:

StateGraph for agents: You can model an agent as a graph with functional nodes, explicit edges, and controlled cycles
Typed state design: Your AgentState has extensible fields (messages, current_plan, iteration_count, tool_results, quality_score, metadata) with appropriate reducers
Cyclic agent loops: You know how to build the research→analysis→conditional check cycle with stop conditions that prevent infinite iteration
Conditional routing: You can create deterministic decision points based on the agent's state
Modular subgraphs: You know how to encapsulate capabilities with clear interfaces

If any of these feels shaky, go back to M4 and shore it up before continuing. This module modifies your Research Agent — you need the foundation to be solid.

From Phase 1 (Modules 1-3)

The agent foundations base is still necessary:

Cognitive architecture (M1): Perceive-reason-act, agent taxonomy, decision framework
Tool use (M2): @tool with schemas, tool execution loop, error handling
Function calling patterns (M3): Parallel calls, routing, structured extraction, retry patterns

From Guide #9 (LangChain & LangGraph)

From the framework you need to handle fluently: StateGraph, TypedDict for state, conditional edges, and executing compiled graphs.

Tools for this module

Python 3.11+
langchain v1.2+ and langchain-openai
langgraph v1.0+
OpenAI API key (GPT-4.1 or GPT-4.1-mini)
tavily-python for web search
python-dotenv for environment variables

pip install langchain langchain-openai langgraph tavily-python python-dotenv

There are no new dependencies compared to M4. The whole stack stays the same.

Module 5 Objectives

By the end of this module you'll be able to:

✅ Implement ReAct in depth: Understand the inner Thought→Action→Observation loop, configure the reasoning's stop conditions, debug the agent's thinking process — not as a black box but as a transparent mechanism
✅ Build plan-and-execute agents: Separate the planning phase (decompose the task into sub-tasks with dependencies) from the execution phase (run each sub-task), with the ability to re-plan when a step fails or the context changes
✅ Implement task decomposition: Break complex tasks into manageable sub-tasks, build dependency graphs between them, and decide when to execute in parallel vs sequentially — with guardrails that prevent excessive decomposition
✅ Add reflection and self-correction: The agent evaluates its own output with specific critique prompts, detects errors or gaps, and corrects itself before delivering — with iteration limits that prevent reflection loops
✅ Capture reasoning traces: Make the agent's reasoning visible at every step — what it considered, what it discarded, why it decided — for debugging, observability, and explainability
✅ Compare reasoning patterns with data: Solve the same case with ReAct vs Plan-and-Execute vs Reflection, measure quality/latency/cost, and argue when each pattern is justified — decisions based on evidence, not intuition
✅ Evolve the Research Agent with planning and reflection: Add intelligent planning nodes, reflection with quality gates, and re-planning to the M4 StateGraph — without rewriting the base, only extending it

Module Map

#	Capsule	What you'll learn
02	ReAct Deep Dive	The inner Thought→Action→Observation loop, opened up and debuggable. Stop conditions for the reasoning. When the agent thinks vs acts. The difference between ReAct as a black box (guide #9) and ReAct as a transparent mechanism you control
03	Plan-and-Execute Agents	Separating planning from execution. The planner generates a structured plan; the executor follows it step by step. Re-planning when a step fails. When plan-and-execute beats plain ReAct and when it doesn't
04	Task Decomposition	Breaking complex tasks into sub-tasks. Dependency graphs. Parallel vs sequential execution. Guardrails: max subtasks, max depth, complexity limits. The anti-pattern of decomposing trivialities
05	Reflection and Self-Correction	Specific critique prompts. The agent as its own reviewer. Quality gates with conditional edges. Max reflection iterations. The risk of the infinite reflection loop and how to prevent it
06	Reasoning Traces and Explainability	Capturing the thinking process as structured data. Debugging the reasoning (not just the code). Observability patterns. The foundation for trajectory evaluation in M9
07	Comparing Reasoning Patterns	Head-to-head: ReAct vs Plan-and-Execute vs Reflection on the same case. Metrics: quality, latency, cost, tool calls. Decision matrix: when to use each pattern depending on context
08	Project: Planning + Reflection	The Research Agent v2: intelligent planning that decomposes, reflection that evaluates, re-planning that covers gaps. New nodes and conditional edges on top of the M4 state machine

Learning flow

The module follows a progression of understand the mechanism → implement the patterns → combine them in the project.

You start with the ReAct deep dive (capsule 02): this isn't re-teaching ReAct — you already used it in guide #9 and mentioned it in M1. Here you open the black box: how does the model decide when to generate a Thought vs an Action? What are the real stop conditions? How do you read and debug a ReAct agent's reasoning? This capsule sets the baseline: you understand the simplest reasoning mechanism before building the more complex ones.

Then plan-and-execute (capsule 03) introduces the first complete deliberative pattern: an agent that plans everything before executing anything. It's the antithesis of ReAct (which interleaves thinking and acting). Here you see the explicit separation: a planner node produces a structured plan, an executor node follows it step by step, and a re-planning mechanism steps in when something fails. The comparison with ReAct isn't theoretical — you implement both for the same task and measure results.

Capsule 04 (task decomposition) digs into the first half of planning: how do you break a complex task into sub-tasks? It isn't trivial. Decomposing too much creates useless overhead. Decomposing too little leaves the task just as complex. You'll learn practical heuristics, dependency graphs for ordering execution, and guardrails that prevent anti-patterns like "generating 50 sub-tasks for a simple question."

With reflection and self-correction (capsule 05), the agent becomes its own reviewer. You implement critique prompts that ask specific questions about the output (not a generic "is this okay?"), quality gates that decide whether to deliver or re-iterate, and guardrails against the reflection loop. This capsule has the biggest practical impact on output quality — an agent that evaluates itself produces significantly better results than one that delivers blind.

Capsule 06 (reasoning traces) closes the observability loop: you capture the agent's thinking as structured data you can inspect, debug, and evaluate. It isn't generic logging — it's the record of the reasoning process that lets you answer "why did the agent reach this conclusion?" This capsule is the direct foundation for M9 (trajectory evaluation) and M10 (production observability).

Capsule 07 (comparing patterns) pulls everything together into a head-to-head analysis. The same use case solved with ReAct, with Plan-and-Execute, and with Reflection. Real metrics: quality of the result, number of tool calls, latency, cost. You produce a decision matrix that tells you when each pattern is justified — the tool you'll use in production to pick strategies.

Finally, the project (capsule 08) applies the three pillars to the Research Agent. It isn't a new exercise — it's the direct evolution of the M4 Research Agent with intelligent planning, reflection with quality gates, and re-planning based on diagnosis.

Connection with the Evolving Project

Research Agent v1 (M4) → Research Agent v2 (M5)

The M4 Research Agent has this structure:

START → planning → research → analysis → [enough?]
                                              ├── YES → synthesis → END
                                              └── NO  → planning (re-iterate)

M5 turns it into:

START → planning_v2 → research → analysis → reflection → [quality ok?]
             ▲                                                  │
             │                                    ┌─────────────┼──────────┐
             │                                    │             │          │
             │                               "re-plan"     "refine"   "deliver"
             │                                    │             │          │
             └────────────────────────────────────┘             │          ▼
                                                                ▼      synthesis → END
                                                         refinement
                                                                │
                                                                ▼
                                                           reflection

What changes concretely

1. The planning node becomes planning_v2

Before (M4):

def planning(state: AgentState) -> dict:
    response = model.invoke(f"Create a search plan for: {state['messages'][-1].content}")
    return {"current_plan": response.content}

After (M5):

def planning_v2(state: AgentState) -> dict:
    if state.get("reflection_notes"):
        prompt = f"""Previous plan had gaps: {state['reflection_notes']['gaps']}
        Create a NEW plan that specifically addresses these gaps.
        Already completed: {state['completed_subtasks']}"""
    else:
        prompt = f"""Decompose this research question into sub-questions:
        {state['messages'][-1].content}
        Return structured plan with dependencies."""

    plan = model.with_structured_output(ResearchPlan).invoke(prompt)
    return {"current_plan": plan, "planning_iterations": state.get("planning_iterations", 0) + 1}

Planning goes from generating free text to producing a structured plan with sub-tasks, dependencies, and context from previous attempts.

2. The reflection node is added

def reflection(state: AgentState) -> dict:
    critique_prompt = f"""Evaluate this research output:
    Original question: {state['messages'][0].content}
    Current output: {state['synthesis_draft']}

    Evaluate:
    1. Does it answer the original question directly?
    2. Are there claims without supporting sources?
    3. Are there obvious gaps the user would expect covered?
    4. Are there contradictions between sources?

    Return structured evaluation."""

    evaluation = model.with_structured_output(ReflectionResult).invoke(critique_prompt)
    return {
        "reflection_notes": evaluation,
        "quality_score": evaluation.quality_score,
    }

3. New conditional edges are added

The post-reflection conditional edge decides between three paths — not just "re-iterate or not":

def route_after_reflection(state: AgentState) -> str:
    reflection = state["reflection_notes"]
    iterations = state.get("planning_iterations", 0)

    if iterations >= MAX_PLANNING_ITERATIONS:
        return "synthesis"  # Guardrail: deliver what you have
    if reflection.recommendation == "deliver":
        return "synthesis"
    if reflection.recommendation == "re-plan":
        return "planning_v2"  # New plan to cover the gaps
    if reflection.recommendation == "refine":
        return "refinement"  # Rewrite without new information
    return "synthesis"  # Safe fallback

4. The state gains new fields

class AgentState(TypedDict):
    # M4 fields (unmodified)
    messages: Annotated[list[BaseMessage], add_messages]
    current_plan: dict
    iteration_count: int
    tool_results: list[dict]
    quality_score: float
    budget_remaining: float
    metadata: dict
    # New M5 fields
    reflection_notes: Optional[dict]
    planning_iterations: int
    completed_subtasks: list[str]
    reasoning_trace: list[dict]
    synthesis_draft: Optional[str]

The M4 fields aren't touched. Only new ones are added. That's the payoff of the extensible state you designed in M4.

What This Module Does NOT Cover

❌ ReAct fundamentals — We don't re-teach what ReAct is or how create_react_agent works at an introductory level. You covered that in M1 and guide #9. Here you open the internal mechanism: stop conditions, debugging the reasoning, advanced configuration
❌ StateGraph fundamentals — We don't re-teach how to create nodes, edges, or compile graphs. That's M4. Here you modify an existing graph to add planning and reflection
❌ Memory or persistence — Plans and reflections live in the state of a single execution. Persisting across sessions is Module 6
❌ Multi-agent planning — A supervisor coordinating planning across multiple agents. That's Module 8. Here a single agent plans and reflects
❌ Formal evaluation — Golden datasets, trajectory evaluation with frameworks, regression testing. That's Module 9. Here you evaluate quality with simple metrics and reasoning traces
❌ Tree-of-Thought, Graph-of-Thought, or advanced o1/o3-style reasoning — More sophisticated reasoning patterns that are still in research or internal to specific models. This module covers the implementable, proven patterns: ReAct, Plan-and-Execute, Reflection
❌ Fine-tuning models for planning — Improving the model's planning ability through training. Here you use off-the-shelf models and control the planning with prompts and structure

The boundary is clear: M5 = how the agent thinks (plans, reflects, reasons). M4 = how execution flows. M6+ = with what additional capabilities it does it.

Evidence of Success

By the end of this module, you'll know you succeeded if:

✅ You can open the ReAct loop and explain Thought→Action→Observation with a concrete example — not as an abstract concept, but showing an agent's real trace
✅ You can implement a plan-and-execute agent that decomposes a task into sub-tasks, executes them, and re-plans when something fails — with working code, not just theory
✅ Your task decomposition has guardrails: max subtasks, max depth, and it doesn't decompose trivial tasks — and you can explain why each guardrail exists
✅ Your reflection produces specific evaluations ("gap: regulations weren't covered") and not generic ones ("the result is fine") — with critique prompts that generate actionable feedback
✅ You capture reasoning traces that let you answer "why did the agent make this decision?" for any step of the process — debugging the reasoning, not just the code
✅ You can solve the same case with ReAct, Plan-and-Execute, and Reflection, compare metrics (quality, latency, cost), and argue when each pattern is justified
✅ Your Research Agent v2 has intelligent planning, reflection with quality gates, and re-planning — and it produces measurably better results than the M4 v1 version

Quick self-assessment test

Ask yourself these questions after completing the module:

"If a ReAct agent doesn't reach the right answer, can I read its reasoning trace and identify where it went wrong?" → If yes, you understand ReAct in depth
"Can my plan-and-execute agent re-plan when step 3 of 5 fails, without repeating steps 1-2 that it already completed?" → If yes, your re-planning is intelligent
"Does my reflection detect specific gaps and does the re-planning cover them, or does the agent basically repeat the same thing?" → If it detects and covers, your reflection is actionable
"Can I decide with data whether to use ReAct vs Plan-and-Execute for a specific case, or do I choose on intuition?" → If you use data, you've mastered the comparison

If you answered yes to all four → ready for Module 6 (Memory Systems). If you answered no to any of them → shore up the corresponding capsule before moving on.

Summary

From reactive to deliberative: M4 controlled the execution flow. M5 controls the intelligence of the decisions inside that flow — plan before acting, reflect after acting, adjust when something fails
Three pillars: Planning (decompose before executing), Reflection (evaluate and correct your own output), Reasoning Traces (make the thinking visible and debuggable)
Thinking has a cost: Planning and reflection add LLM calls, latency, and tokens. This module gives you data to decide when that cost is justified — not always, not never, but depending on the complexity and stakes of each task
The Research Agent evolves: The planning node becomes intelligent, a reflection node with quality gates is added, and re-planning covers specific gaps instead of repeating the same strategy
An extensible state pays off: The new fields (reflection_notes, planning_iterations, reasoning_trace) are added without modifying the M4 ones. That's the advantage of an extensible design
Comparison with data, not dogma: ReAct, Plan-and-Execute, and Reflection aren't "better" or "worse" — each has measurable trade-offs. You choose with evidence, not preference
Analytical tone: This module is an engineer evaluating options — not an evangelist for a pattern. The data decides, not the narrative

Resources

ReAct: Synergizing Reasoning and Acting (Paper) — The original paper that formalized the Thought→Action→Observation loop. Theoretical foundation of the most used pattern in agents
Reflexion: Language Agents with Verbal Reinforcement Learning (Paper) — The paper that introduced self-reflection in agents. Foundation of this module's reflection patterns
Plan-and-Solve Prompting (Paper) — Task decomposition and planning as a prompting strategy. Academic evidence for why planning improves results
LangGraph: Plan-and-Execute — Official LangGraph tutorial for plan-and-execute agents. Reference implementation
LangGraph: Reflection — Official LangGraph tutorial for reflection patterns. Reference implementation
Building Effective Agents — Anthropic — Anthropic's perspective on planning and reflection in agents. Complements the LangChain/LangGraph approach

← Previous8. Project: Research Agent with a State Machine Next →2. ReAct Deep Dive