Chapter 7: Planning and reflection for complex tasks

Introduction

Introduces why a reactive agent can struggle with multistep tasks and how planning and reflection address different parts of that problem.

• Reactive agent limitations: Explain why an agent that repeatedly observes and chooses a tool can struggle with complex, multistep tasks, even when it has memory.
  Why it matters: It explains why adding memory alone may not be enough for a complex task.
• Planning and reflection roles: Distinguish planning from reflection as the two ways this section proposes giving an agent time to think.
  Why it matters: The distinction shows how an agent can set a direction and later reconsider it.

Key terms: reactive approach, memory systems, planning, reflection

7.1 Giving agents time to think

Introduces planning and reflection as ways to give agents time to think and previews the topics that follow.

7.1.1 The limitations of ReAct

This section explains why ReAct’s adaptable, step-by-step decisions can lose direction on complex tasks.

• ReAct’s Local Adaptability: Describe how a ReAct agent chooses each action from the current situation and why that lets it adapt when results differ from expectations.
  Why it matters: ReAct’s strength helps explain why its limitations are most apparent on longer, more complex tasks.
• Complex Task Failure Modes: Explain why choosing only the next locally sensible action can fail on complex tasks, using examples from the section.
  Why it matters: Recognizing the shared cause of these failures clarifies why complex tasks need more than responsive next-step choices.

Key terms: ReAct, tool, max_steps

7.1.2 How human experts work

This section uses researchers and software developers to show why agents should plan complex work and check their progress against that plan.

• Expert approach to complex questions: Describe how a skilled researcher breaks a complex question into parts, investigates them in an organized way, adjusts when results call for it, and checks for missing pieces before answering.
  Why it matters: The researcher’s process provides a concrete model for handling complex tasks deliberately rather than rushing to an answer.
• Plans and progress checks: Explain how software developers and coding agents use a spec or implementation plan to guide work, revisit it when problems arise, and check progress against it; relate these activities to planning and reflection.
  Why it matters: It connects familiar development practices to the planning and reflection capabilities the chapter adds to agents.

Key terms: decompose, investigate, adjust their approach, product requirements document (PRD), spec document, implementation plan, planning, reflection

7.1.3 Why time to think matters

This section explains why giving agents time to think can improve their work and how planning and reflection guide later decisions by adding text to the agent’s context.

• Value of intermediate reasoning: Explain why giving an LLM time to generate intermediate reasoning can improve performance compared with requiring an immediate answer.
  Why it matters: This is the reason the section gives agents opportunities to think rather than only act.
• Planning and reflection roles: Distinguish planning before action from reflection after action, including the questions each helps an agent address.
  Why it matters: The distinction explains the two ways an agent can examine and guide its own work.
• Generated context signals: Explain how planning and reflection guide an agent’s workflow through generated text in its context, rather than by performing tasks directly.
  Why it matters: It clarifies how thinking can steer an agent’s next action without itself searching, calculating, or reading a file.

Key terms: chain-of-thought prompting, intermediate reasoning steps, thinking tokens, planning, reflection, metacognition, context engineering, generation strategy, retrieval, writing

7.2 Planning: Setting direction

Planning gives a complex task direction by breaking it into manageable steps with clear completion criteria.

• Planning through task decomposition: Explain how breaking a complex question into smaller tasks gives an agent direction. Use the Kipchoge-to-the-Moon example to describe the steps and how the agent could check its progress.
  Why it matters: A plan helps an agent stay directed and check its progress on a complex task.

Key terms: planning, decomposition, completion criteria

7.2.1 When planning is necessary

This section explains when an agent should plan, when it should skip planning, and why that distinction belongs in the planning tool’s description.

• Planning necessity by task: Distinguish tasks that warrant planning from tasks that do not: multistep research or combining information calls for planning, while a single-search question or a task with a clear procedure does not. Explain that unnecessary planning costs LLM calls, tokens, and time.
  Why it matters: Choosing when to plan avoids spending extra time and tokens on tasks that do not need it.
• Planning tool usage guidance: Explain why the planning tool’s description must say when to use the tool and when not to use it.
  Why it matters: The agent needs explicit guidance to avoid invoking planning for unsuitable tasks.

Key terms: planning, multiple steps of research, single search, clear procedures, planning tool, description

7.2.2 Implementing the planning tool

This section builds a simple planning tool by choosing how to store and update a plan, formatting task progress, and leaving planning decisions to the LLM.

• Simple plan management: Explain why the tool keeps one plan per question and regenerates the whole plan when it changes, rather than managing multiple plans or editing individual tasks.
  Why it matters: These choices keep the first planning tool simple without requiring fragile plan-editing logic.
• Task progress representation: Describe what a Task stores and how its string representation shows pending, in-progress, and completed work.
  Why it matters: A readable task list lets the LLM see both the work and its current progress.
• Planning tool responsibilities: Trace what the create_tasks tool does with a task list and distinguish that work from the LLM’s planning and state management.
  Why it matters: This division of labor explains why a useful planning tool needs very little implementation logic.
• Planning tool description: Explain how the tool description guides when the LLM should call the planning tool and how it should update task statuses.
  Why it matters: A clear description helps the LLM use planning when it is useful without calling the tool unnecessarily.

Key terms: plan, subplans, partial modifications, Task, __str__, pending, in_progress, completed, create_tasks, @tool

7.2.3 Planning-tool example

This example shows an agent creating and updating a plan, then explains how task granularity affects execution time.

• Plan creation and progress tracking: Trace how the agent calls create_tasks to make a plan, records the result in context, and updates task statuses as work progresses. Explain how the recorded plan helps the LLM choose subsequent steps.
  Why it matters: A plan is useful during execution because the agent can revisit it and track what to do next.
• Choosing useful task granularity: Explain why overly fine-grained plans can slow execution and how instructions can encourage the LLM to group related work into meaningful tasks.
  Why it matters: Grouping related actions keeps planning and status updates from consuming unnecessary execution time.

Key terms: create_tasks, ToolResult, context, completed, in_progress, checkbox format, granularity, WHEN TO USE, WHEN NOT TO USE, instructions parameter

7.2.4 Extension directions

This section describes ways to extend a simple planning tool for complex tasks while arguing that useful planning questions matter more than added structure.

• Planning tool extension options: Describe how completion criteria, task/action hierarchies, and dependencies can extend a simple planning tool for complex tasks.
  Why it matters: These options address different planning problems without requiring every task to use all three.
• Question first planning approach: Explain why the section recommends guiding the LLM with planning questions before adding structural complexity.
  Why it matters: Good planning guidance may help without the cost of implementing dependency graphs or hierarchy management.

Key terms: completion criteria, hierarchical structure (task/action), dependency management (deps), tool’s description, dependency graphs, parallel execution

7.3 Reflection: Checking and correcting

This section explains reflection as a pause during an agent’s work to assess progress and guide later decisions.

• Reflection during agent work: Distinguish reflection from planning and describe why an agent should pause to check its progress rather than only choose the next action.
  Why it matters: A pause to assess progress can keep an agent from simply pressing ahead when its evidence or approach calls for reconsideration.
• Recorded evaluation and direction: Explain what an agent assesses during reflection and how recording that assessment affects subsequent LLM decisions.
  Why it matters: Putting an assessment into context makes it available when the LLM decides what to do afterward.

Key terms: planning, reflection, ReAct agents, context, evaluation and direction so far

7.3.1 When reflection is necessary

This section identifies useful checkpoints for agent reflection, explains when reflection adds unnecessary overhead, and distinguishes it from summarization.

• Reflection checkpoints during work: Describe when an agent should pause to reflect: after a meaningful plan stage, after a tool error, while reconciling gathered information, and before giving a final answer. Explain what the check helps the agent do at each point.
  Why it matters: Choosing these checkpoints helps an agent correct course rather than carry mistakes into later work or its final answer.
• Selective use of reflection: Explain why an agent should not reflect after every tool call, especially when a simple operation is proceeding as expected.
  Why it matters: Selective reflection preserves the benefit of checking without slowing down routine progress.
• Reflection versus summarization: Distinguish reflection from summarization by their triggers and purposes: selective checking and correction versus automatic compression when context length passes a threshold.
  Why it matters: The distinction prevents a context-saving operation from being mistaken for a check on whether the agent's work is going in the right direction.

Key terms: reflection, checkpoint, max_steps, self-verification, overhead, summarization, context length, token count

7.3.2 Implementing the reflection tool

This section implements reflection as LLM-written analysis stored in the agent’s context, with guidance on when to reflect and a flag for revisiting an invalid plan.

• Reflection as recorded evaluation: Explain how the reflection tool uses the LLM’s judgment: it returns the supplied analysis as a string, which is recorded as a ToolResult for later decisions.
  Why it matters: The stored reflection can influence what the agent decides to do next.
• Flexible reflection input: Justify why the reflection parameter accepts free-form text rather than a fixed structure.
  Why it matters: A flexible input lets the agent record the kind of assessment its current situation calls for.
• Reflection use situations: Describe the four situations named in the tool description and why including examples of them helps.
  Why it matters: The description helps the LLM recognize when a reflection call is appropriate.
• Replanning coordination signal: Explain what the need_replan flag signals and what setting it to True encourages.
  Why it matters: Reflection can signal that continuing with the current plan is no longer appropriate.

Key terms: reflection tool, ToolResult, context, evaluation so far, reflection parameter, free-form text, PROGRESS REVIEW, ERROR ANALYSIS, RESULT SYNTHESIS, SELF CHECK

7.3.3 The real value of reflection: Failure recovery

This section shows how reflection helps an agent recover from a failed tool call by analyzing the error and choosing an alternative.

• Reflection for tool failure recovery: Trace how the agent responds when its Wikipedia tool fails: it records an error analysis, identifies web search as an alternative, and uses that analysis to guide its next step.
  Why it matters: When a tool fails, analyzing the error can keep the agent from wasting steps on the same failing call.

Key terms: reflection, ERROR ANALYSIS, RuntimeError, search_web, max_steps

7.3.4 Running an agent that uses reflection for research synthesis

This subsection shows how reflection helps an agent organize search results and decide when to answer.

• Reflection for research synthesis: Explain how reflection helps an agent synthesize results from multiple searches and move toward an answer.
  Why it matters: Reflection can help an agent turn a collection of search results into a decision to answer.

Key terms: reflection, synthesizes, context

7.4 Integrating planning and reflection

This section shows how planning and reflection work as a cycle and how, together, they address four weaknesses of a reactive ReAct agent.

• Planning and reflection cycle: Trace how an agent plans ordered tasks, executes them with tools, and reflects on progress before continuing or revising its plan.
  Why it matters: The agent can follow a direction without continuing blindly when the work changes.
• Plan change decision: Distinguish a failed method that calls for a different tool from a changed premise that calls for replanning, and describe how need_replan triggers that return to planning.
  Why it matters: The distinction prevents an agent from rebuilding a sound plan for a tool outage or persisting with a plan built on a false premise.
• Direction and answer completeness: Explain how planning addresses lost direction and how planning together with reflection prevents the agent from answering before it has enough information.
  Why it matters: A clear task order and a final check reduce both scattered work and premature answers.
• Progress retention and failure recovery: Explain how task status and progress review help an agent retain prior work, and how error analysis helps it recover rather than repeat a failed attempt.
  Why it matters: Recorded progress reduces repeated work, while an explicit account of failure gives the agent a different next step.

Key terms: planning, reflection, tools, need_replan, create_tasks, context, replanning, losing direction, completion criteria, SELF CHECK

7.5 Summary

The section summarizes how planning and reflection help agents maintain direction, recover from failures, and shape subsequent decisions through context.