Planning, Reasoning and Decision Making

Suppose your goal is to make a sandwich. Reasoning helps you understand that there is no bread. Planning arranges steps such as getting bread before adding filling. Decision-making chooses the next action: walk to the shop, change the meal, or ask someone for help.

Current situation → Reason about it → Plan possible steps → Choose one action
                                                        ↓
                                                   Observe result

What You Will Learn

• The simple difference between reasoning, planning, and decision-making.
• How the model’s generated decisions differ from orchestration rules in code.
• When planning ahead helps and when one-step decisions are enough.
• How observations can invalidate a plan and trigger replanning.
• How to keep plans bounded, testable, and safe in production.

Modules 4 and 5 both quietly assumed something: that at each step of the loop, the agent could figure out what to do next. This module is where we stop assuming that and explain how.

Two words are going to carry most of the weight here — reasoning and planning — and they get used almost interchangeably in casual conversation about agents, which is a real problem, because they’re doing different jobs, they fail in different ways, and confusing them leads to real design mistakes.

By the end of this module you’ll have precise language for both, plus something that matters more than either term individually: a clear, honest line between what the underlying model is doing and what your own orchestration code is doing around it.

What reasoning is

Reasoning, in the context of an agent, is the model generating text that represents its own analysis of the current situation before it commits to a decision. You already saw an example of this back in Module 4: *“the payment history shows two declines for insufficient funds, which doesn’t match the customer’s claim of a gateway issue — I should verify the gateway’s status before concluding anything.” * That sentence isn’t decoration.

It’s the model working through what it currently knows, out loud, in a way that both tends to produce better downstream decisions and gives you, the engineer, real visibility into why a particular action got chosen.

It’s worth being careful and precise about what this is, because it’s exactly the kind of thing that invites overclaiming. This reasoning text is a generation — text produced the same way any other model output is produced, following patterns learned during training, conditioned on whatever’s currently in the prompt. It is not a window into some separate cognitive process happening elsewhere in the model, and it’s not evidence that the model is “thinking” the way a person does.

The honest, accurate description is narrower and, frankly, still useful: asking a model to produce this kind of intermediate analysis before answering tends to improve the quality of its eventual output, and it gives you a legible trace of the decision process — two real, practical benefits that don’t require any claim about what’s “really” happening inside the model to be true.

The distinction that matters most in this whole module

Here’s the idea worth carrying forward more than any other single thing in this module: the model’s reasoning capability and your agent’s orchestration logic are two different things, and building a reliable agent depends on understanding exactly where the line between them sits.

The model’s reasoning capability is what it does within one generation — how well it can work through a problem when prompted to, how coherent and well-grounded its intermediate analysis is, how reliably it notices a contradiction (like the payment-mismatch moment in Module 4). This varies by model, and a more capable model will often reason more reliably.

Orchestration logic is everything around that — the code that decides how many reasoning steps are allowed before forcing a stop, the code that validates a tool call’s arguments before executing it, the code that decides whether a failed action gets retried or triggers a strategy change, the code that enforces a hard iteration cap regardless of what the model believes about its own progress. None of this is the model reasoning. It’s the surrounding engineering that determines whether good reasoning, when it happens, translates into reliable behavior.

This distinction isn’t abstract — it shows up as a, deliberate design choice in real, shipped systems, and it’s worth looking at one directly, because the two features involved are easy to conflate and the company that built both went out of their way to explain why they’re different.

Anthropic’s Claude models support a feature called extended thinking, where the model produces a visible “thinking” block — working through a problem step by step — before its final answer, returned to you as a separate content block you can inspect. This is reasoning capability, built into the model itself: given enough space and permission to think before answering, the model works through harder problems more effectively. (Anthropic, Claude’s extended thinking)

Separately, Anthropic also documented something they explicitly called the “think” tool — and they were careful to note it’s a different concept from extended thinking, even though the names sound similar. The think tool isn’t a model capability at all.

It’s an ordinary tool, in exactly the sense you learned about in Module 5 — something the model can choose to call mid-task, giving it a defined, designated space to pause and check whether it has enough information before continuing with a complex, multi-step tool-use situation.

Anthropic’s own framing is worth quoting directly, because it states this distinction more precisely than a paraphrase would: extended thinking is about what the model does before it starts generating a response, while the think tool is for the model, once it’s already generating a response, to add a deliberate step where it stops and thinks about whether it has what it needs before going further. ([Anthropic Engineering, The “think” tool](https://anthropic. com/engineering/claude-think-tool))

Sit with that distinction for a second, because it’s exactly the line this module has been building toward. Extended thinking is model capability — a way of letting the model reason more thoroughly within its own generation. The think tool is orchestration — a designed mechanism, implemented as a callable action just like any other tool, that structures when and how reflection happens during a longer agentic task.

Two different things, built by the same company, deliberately kept distinct — because conflating them would mean losing the ability to reason clearly about which one to reach for when an agent’s behavior needs improving. If an agent’s individual decisions seem shallow, that’s a reasoning-capability problem — more thinking space, a different model, a more capable one.

If an agent loses track of what it’s already established across a long, multi-step task, that’s often an orchestration problem — a missing checkpoint, not a missing IQ point.

Reflection and verification: reasoning applied to the model’s own output

Two more terms worth being precise about, because they’re specific, useful applications of the general reasoning capability described above, not separate mechanisms.

Reflection is the model evaluating its own prior output or decision before proceeding — asking “does this answer what I needed, or am I missing something?” Verification is checking a result or conclusion against some independent standard rather than simply trusting it at face value. Go back to Module 4’s wrong-diagnosis scenario — the duplicate-authorization charge that looked successful but wasn’t.

An agent with a verification habit, prompted or structured to check a “successful” payment result against a second, independent signal before concluding the issue was resolved, would have had a real chance of catching that trap before it mattered.

This is precisely why reflection and verification steps are worth building deliberately into an agent’s design for tasks where the cost of a wrong conclusion is high — they’re not a nice-to- have, they’re a direct mitigation for exactly the subtle wrong-diagnosis failure mode covered earlier in this course.

Planning: structuring the work before doing it

Planning is a distinct capability from reasoning, worth keeping separate in your head: it’s producing a rough decomposition of a task before diving into individual actions, rather than discovering the task’s structure purely reactively, one step at a time. Compare the two shapes directly:

Direct execution

Goal → Action → Action → Action

Planned execution

Goal
 ↓
Create plan
 ↓
Step 1
 ↓
Step 2
 ↓
Step 3
 ↓
Evaluate
 ↓
Replan if necessary

Direct execution is what our support agent did throughout Module 4 — each observation naturally suggested the next step, with no explicit upfront structure needed. This works well when a task’s dependencies are simple enough to discover as you go. Planned execution adds a real, useful layer for tasks where the structure is complex enough that anticipating it upfront helps: identifying subtasks, noticing which ones depend on others, and sequencing work sensibly rather than stumbling into a dependency mid-execution and having to backtrack.

Task decomposition and step selection

Task decomposition is the actual act of breaking a broad goal into smaller, more tractable pieces. For a more complex version of our support scenario — say, a billing dispute spanning three separate subscriptions with overlapping charges — a reasonable decomposition might look like: “identify every affected subscription, pull the billing history for each one independently, cross-reference for duplicates versus legitimate separate charges, then determine the correct resolution for each.”

Each of those is a real, distinct piece of work, and naming them upfront, rather than discovering the need for each one reactively, gives the agent (and you, watching the trace) a much clearer sense of whether it’s making progress.

Step selection is the ongoing decision of which planned step to execute next, particularly when steps have real dependencies between them. In the billing example, “pull the billing history for each subscription” needs to happen before “cross-reference for duplicates” can be done meaningfully — the plan needs to respect that ordering, and a well-designed planning step should recognize dependency relationships like this rather than treating every step as independently orderable.

Dynamic planning and replanning

Plans made in advance don’t always survive contact with what gets discovered. Dynamic planning means adjusting the plan mid-execution when new information reveals the original structure was incomplete or wrong. Replanning is the specific act of doing that revision.

You already saw a small, real instance of this back in Module 4, even though we didn’t name it as planning at the time. When the support agent discovered the payment-history mismatch in iteration 2, it didn’t just note the fact and continue with whatever the original, implicit plan had been — it changed course, adding a gateway check that wasn’t part of the initial approach. That’s replanning at a small scale: a discovery invalidating part of the original approach, and the agent restructuring what happens next in response, rather than blindly continuing.

A more structured example, back in the billing-dispute scenario: if cross-referencing the three subscriptions’ histories reveals that one of them isn’t the customer’s account at all — a data-entry error somewhere upstream — the correct response isn’t to continue the original three-subscription plan with a note about the anomaly. It’s to replan: the goal itself may need reframing around only the two subscriptions that are the customer’s, with the third flagged separately as a distinct issue worth its own resolution.

When planning earns its keep, and when it doesn’t

This is worth stating plainly, because the instinct once you learn about planning is to assume more structure is always better, and that’s not true.

Planning earns its keep when a task has real structure worth anticipating — multiple subtasks, real dependencies between them, and enough complexity that discovering the shape of the work purely reactively would mean real backtracking and wasted effort. The billing-dispute example above benefits from this.

Planning is unnecessary overhead when a task is simple enough that each step naturally suggests the next one, the way the original payment- diagnosis example in Module 4 did. Building an explicit upfront plan for a task that direct execution already handles cleanly adds real latency and real complexity — an extra reasoning pass, more tokens spent, more surface area for something to go subtly wrong — with no corresponding benefit. The engineering judgment here mirrors something you’ll see again in Module 8: match the mechanism to the task’s actual complexity, not to what sounds more sophisticated.

Where this shows up in real, current agent products

It’s worth seeing this distinction — planning-heavy versus reactive — reflected in real, different product design choices. Research-focused agentic products, the “deep research” style tools now offered by several major AI labs, are deliberately planning-heavy: before running any searches at all, they produce an explicit outline of sub-questions the research needs to answer, then work through that outline systematically, adjusting it as findings come in. This makes sense given the job — a broad research task has real structure worth anticipating, and jumping straight into ad-hoc searching would waste real effort rediscovering that structure along the way.

Compare that to AutoGPT’s original design, referenced repeatedly throughout this course, which leaned almost entirely reactive — a task queue that got reprioritized based on each step’s result, with far less upfront structural thinking about the shape of the overall goal before diving in. That looseness is a real contributor to the unpredictability that made those early systems hard to trust, and it’s a useful contrast: the more planning-disciplined research tools represent a maturing of the same underlying idea, applied more deliberately.

Three real examples where you can see all three, separated

If planning, reasoning, and decision-making still feel like they blur together, that’s a fair reaction — from the outside, they can all look like “the model producing text before doing something.” The best way to pull them apart is to watch a real product where the three are structurally separate, not just conceptually separate, and trace exactly what’s happening at each stage.

**Claude Code’s Plan Mode is the clearest real illustration available. ** When you activate it, Claude Code enters a hard, tool-level enforced read-only state — file-editing and shell-mutating tools are unavailable, not just discouraged. In that state, Claude explores your codebase using read-only tools (the Read, Grep, and Glob tools from Module 5), and produces a structured plan — a real, standalone markdown document — describing the approach, before requesting your approval through a dedicated ExitPlanMode action. ([Claude Code Plan Mode documentation, via GetAIPerks](https://www.

getaiperks. com/en/ai/claude-code-plan-mode)) That entire phase — explore, structure an approach, write it down, request approval — is planning, in exactly the sense this module has been using the word: a deliberate decomposition of the work, produced before any execution begins.

Reasoning is what’s happening within that exploration, at each individual step — Claude working through what a specific piece of code does, what a bug’s root cause likely is, what approach would handle an edge case correctly. This is the same capability covered earlier in this module under extended thinking — useful intermediate analysis, visible in the trace, distinct from the plan itself. The plan is the output of a lot of this reasoning, condensed into a structured document; the reasoning is the process that produced it.

Decision-making is narrower still, and it happens twice, in two different moments. First, during the planning phase itself, each individual choice of which read-only tool to reach for next — Grep to search file contents, Glob to find a file by name — is a decision, informed by the reasoning happening at that moment.

Second, once you approve the plan and execution begins, every subsequent tool call — this specific Edit, this specific Bash command — is another decision, now made against the already-established plan rather than discovering the approach fresh. Same underlying model, three different jobs happening at three different moments: plan the approach, reason through each piece of it, decide on each concrete action.

**OpenAI’s deep research tools show the same three-way split for a different kind of task. ** Before running any searches, these tools produce an explicit outline of the sub-questions the research needs to answer — planning. As each source comes back, the model reasons about whether it’s relevant and credible enough to rely on — reasoning.

And at each point, it decides whether to search further, which specific query to run next, or whether enough has been gathered to synthesize a final answer — decision-making. The planning phase here is what keeps a broad, open-ended research task from turning into directionless, ad-hoc searching; the reasoning is what keeps any one source from being trusted uncritically; the decisions are what move the task forward, step by step, informed by both.

And you can see the same three-way split in our own recurring support agent from earlier in this course, even though it never used an explicit upfront plan the way Claude Code or a research tool does. Planning was minimal and implicit — “check the account first, then payment history” — appropriate for a task simple enough not to need more. Reasoning showed up explicitly at the payment-mismatch moment in Module 4, when the agent worked through why the customer’s claim didn’t match the data.

Decision-making happened at every single step — which tool to call, whether to continue or verify further, when to finally stop. The three concepts didn’t disappear just because the task was simpler than a coding change or a research report — they were just proportioned differently, exactly matching this module’s earlier point that planning earns its keep in proportion to a task’s complexity, while reasoning and decision-making are present in some form at essentially every step, regardless of scale.

Numbered Walkthrough: Reason, Plan, Decide

An agent has ₹500 and must buy three notebooks costing ₹120 each plus one pen costing ₹80.

1. Reason about the facts: notebooks cost 3 × ₹120 = ₹360; adding the pen gives ₹440, which is within the ₹500 limit.
2. Create a plan: check stock, add the three notebooks, add the pen, verify the total, and request approval before purchase.
3. Make the next decision: check stock first because later steps depend on availability.
4. Observe: the store reports only two notebooks in stock.
5. Replan: do not continue with the old three-notebook plan; search an approved second store or ask the user whether two notebooks are acceptable.

Reasoning interprets the numbers, planning arranges possible steps, and decision-making selects the next step under the current conditions.

Common Misconception

Incorrect idea: A longer plan always means the agent reasoned better.

Why it is incorrect: Long plans can become outdated after the first unexpected result. Use enough planning to guide the next safe actions, then re-evaluate with fresh observations.

Key Takeaways

• Reasoning is the model generating intermediate analysis before deciding — useful for both decision quality and visibility into an agent’s behavior, but it’s a generation like any other, not evidence of the model “thinking” the way a person does.
• The model’s own reasoning capability and your agent’s orchestration logic are different things, and Anthropic’s own extended thinking (a model capability) versus its “think” tool (an orchestration mechanism implemented as a callable tool) is a real, documented illustration of exactly this distinction.
• Reflection (checking your own prior output) and verification (checking a conclusion against an independent standard) are specific applications of reasoning, worth building deliberately into agents where a wrong conclusion carries real cost.
• Planning is producing a rough decomposition of a task before diving into individual actions — distinct from reasoning, and useful specifically when a task has real structure and dependencies worth anticipating.
• Task decomposition breaks a goal into tractable subtasks; step selection decides which planned step to execute next, respecting dependencies between them.
• Dynamic planning and replanning mean revising the plan when new information invalidates part of it — you already saw a small, real instance of this in Module 4’s payment-mismatch moment.
• Planning earns its keep for complex, structured tasks and is unnecessary overhead for simple ones — matching the mechanism to the task’s actual complexity is the real engineering judgment, not a default toward more structure.

Think Like an AI Engineer

• Go back to the billing-dispute example decomposition in this module. Which of its steps depend on another step finishing first, and which could, in principle, be tackled in either order? What would change about the plan if two of the three subscriptions turned out to be independent of each other?

• Design a reflection check for an agent that drafts customer-facing emails before sending them. What specific question should that reflection step ask itself, and what would a “fail” on that check look like in practice?

• A colleague argues that every agent should always build an explicit plan before acting, because “more structure is always safer.” Using this module’s framing, what’s the strongest counterargument you can make? Give a concrete example of a task where an explicit plan would be wasted effort.

• Anthropic kept extended thinking and the think tool deliberately separate rather than merging them into one feature. Based on this module, what would be lost if they’d been combined into a single, undifferentiated “make the model think more” setting?

Module 7 takes on the distinction that trips up more beginners than almost anything else in this subject: context, state, and memory. We’ll use the flight-booking example to make the difference between these three concretely, permanently clear — and connect it back to what you already know about RAG from earlier in this course.