The Reasoning Technique Taxonomy
Ask a reactive agent — a loop that thinks, calls a tool, reads the result, and responds, one step at a time — to plan a Saturday in Edinburgh: brunch near the university, a museum if it rains, a sunset viewpoint, and a vegetarian dinner that takes bookings, minimizing walking. Here is exactly what it does, in order, and exactly where each step quietly breaks the task:
Prerequisite: Lesson 13, Managing Context at Scale — this lesson assumes you can already keep a reactive agent's context window under control across many tool calls. It opens a new arc: everything up to now was about the agent's hands and its memory budget; from here, it's about whether the agent has a strategy before it starts using them. After this lesson, you can: name the specific architectural gap that makes a reactive agent fail on a multi-step task, and place any reasoning technique you encounter — a paper, a product feature, a framework flag — correctly on the spectrum between "improves one step" and "coordinates many steps."
Where the reactive loop breaks, step by step
No dependency check against what comes later — the agent has no way to know this choice constrains the museum search two steps from now.
Nothing in the loop planned a weather check as its own step, so the rain condition never gets evaluated at all.
The constraint was never tracked as global — each step optimizes alone, so a dinner spot far from the viewpoint looks locally fine.
Too late to do anything about it. Nothing upstream was watching for a constraint that only surfaces this late.
The instinct is to blame the model: try a bigger one, write a better prompt, add a few more examples. That instinct is wrong, and this lesson's whole argument is why.
The four ways a reactive agent breaks, and none of them are about intelligence
Run the Edinburgh itinerary through a reactive loop and you get four distinct, nameable failures — not one vague "it got confused."
| Failure Pattern | What Happens | Root Cause |
|---|---|---|
| Premature Commitment | Books brunch without checking what's near the museum | No dependency awareness |
| Cascading Invalidation | Dinner venue is booked, no alternative, whole evening fails | No contingency plan |
| Constraint Blindness | Ignores "minimise walking" because each step optimises alone | No global objective |
| Context Amnesia | By step 7, the agent has forgotten step 2's constraints | Context window filling up |
Look at the root-cause column, not the symptom column. None of these four say "the model reasoned incorrectly." Each one names something the architecture never gave the agent: a way to see dependencies between steps, a fallback when a step fails, a persistent objective that survives every individual tool call, a memory that doesn't erode as the conversation grows. A stronger model dropped into the same reactive loop still has no dependency graph, no contingency slot, no persistent objective check, and no defense against its own context filling up. It will reproduce all four failures, just with more articulate reasoning at each individual step along the way.
"Locally correct at each step" and "globally coherent across a task" are different properties. A reactive agent can nail every individual search, every individual calculation, every individual tool call — and still fail the task, because nothing in the architecture is responsible for the task as a whole. Scaling the model scales the first property. It does nothing for the second.
That distinction is worth making precise, because "reasoning" and "planning" get used interchangeably in casual conversation and they are not the same operation. Reasoning generates intermediate logical steps to reach a conclusion from information the model already has: given what I know, what follows? Planning constructs a sequence of future actions under constraints and uncertainty: what steps, in what order, and what happens when one of them fails? A model can reason flawlessly about each of six sub-questions in the Edinburgh problem and still never coordinate those six answers into one itinerary that actually works, because coordinating them was never the job reasoning does.
This is this week's central claim, and it's worth stating as a position rather than a hedge: an agent that plans before it acts, and replans when a step fails, is not incrementally better than a reactive agent — it can complete tasks a reactive agent cannot complete at all, no matter how capable the underlying model gets. The rest of this course builds toward that architecture. This lesson's job is narrower: give you the vocabulary to place every reasoning technique you'll meet — in a paper, a product changelog, a vendor's marketing copy — on the actual spectrum between "improves one step" and "coordinates a whole task."
Where this sits in 55 years of trying to make machines plan
Planning is not a 2022 invention. STRIPS (1971) searched over preconditions and effects to find action sequences. PDDL (1998) standardized how a planning problem gets specified. HTN planning broke high-level goals into atomic steps hierarchically. BDI agents (Beliefs, Desires, Intentions, 1990s) mixed reactive and deliberative behavior explicitly. Then, for roughly two decades, neural approaches to language modeling largely bypassed explicit planning representations — until Chain-of-Thought (2022) showed that a language model could emulate step-by-step reasoning without anyone hand-coding a search algorithm. Reasoning models (2024) took that further, training extended deliberation directly via reinforcement learning. The Planner-Executor split (2025-26) is where this history and the neural turn meet: planning grounded in natural language instead of predicate logic, but still built on the old insight that deciding what to do and doing it are separate jobs.
The lens for the rest of this week: Lambert's four traits
Nathan Lambert, at the Allen Institute for AI, proposed in 2025 that a reasoning model needs four distinct traits to function as an effective autonomous agent, and rated where each one stood as of 2026:
| Trait | Definition | Status in 2026 |
|---|---|---|
| Skills | Atomic problem-solving: math, code, tool use | Largely solved |
| Calibration | Knowing how hard to think on a given problem | Improving (effort selectors) |
| Strategy | Choosing the right high-level approach first | Active frontier |
| Abstraction | Breaking a goal into the right-sized chunks | Hardest open problem |
Map this onto the Edinburgh problem and the four traits stop being abstract. Skills is "can the model call a search API and parse the result" — yes, solved, boring. Calibration is "should I spend real reasoning effort on which brunch spot, or just pick one and move on." Strategy is "should I fix meals first and route around them, or fix the route first and fit meals into it." Abstraction is "is 'find a good restaurant' one step, or does it actually need five — dietary filter, distance, booking, price, backup option." A reactive agent has Skills. It has nothing else on this list, which is exactly why the four named failures above are Calibration, Strategy, and Abstraction gaps wearing an "the model wasn't smart enough" costume.
Seven techniques, one spectrum
Every reasoning technique below trades simplicity for capability, in a fairly strict order. None of them is "best" — the right one depends on how much coordination the task actually needs. This taxonomy is what you'll use to place any paper, framework feature, or vendor claim you meet from here on.
Ask the model to show intermediate steps before answering. "What is 17 × 23?" answered directly sometimes lands on the wrong number; asked to think step by step, the model produces "17 × 20 = 340, 17 × 3 = 51, 340 + 51 = 391" and each intermediate token constrains the next, acting as a scratchpad that catches compounding errors. The limitation is architectural, not a matter of degree: CoT is linear and single-path. An error at step 2 contaminates every step after it, with no backtracking and no alternative path considered. In Lambert's terms, CoT improves Skills. It does nothing for Strategy or Abstraction, because it never considers more than one line of reasoning.
Samples the same CoT prompt N times at nonzero temperature and takes the most common final answer — the correct answer tends to be a statistical attractor even when individual chains wander. It helps most on problems like math word problems, where reasoning paths sometimes go wrong but converge on the right answer more often than any single wrong path repeats. The cost is linear in N: twenty chains at a thousand tokens each is twenty thousand tokens for one question. It's still fundamentally a Skills technique — it fixes random errors statistically — though high agreement across samples starts to function as a confidence signal, a first, crude touch of Calibration.
Stops committing to one chain. At each point it generates multiple candidate next steps, evaluates them, pursues the strongest branches, and prunes dead ends — breadth-first, depth-first, or beam search over the space of partial reasoning paths. This is expensive: a tree with branching factor 3 and depth 4 is up to 81 LLM calls. But it's the first technique on this list that directly addresses Strategy, because it explores alternatives before committing rather than walking a single line and hoping. It's the bridge from reasoning to planning-style thinking.
Interleaves reasoning with tool calls: Thought, Action, Observation, repeat, until the model emits a final answer grounded in what the tools actually returned rather than what the model assumes. This is the scaffold you already know from the reactive loop — it grounds reasoning in real outputs and meaningfully reduces hallucination, but it is still linear. It decides what to do next only after seeing the previous observation, with no global plan, which is exactly why it struggles past roughly ten sequential steps. Lesson 15 builds this one by hand.
Adds memory across attempts: after a failure, the agent writes a verbal reflection — "I failed because I searched for X instead of Y; next time I should" — and that reflection gets injected into the next attempt's prompt. This is the "don't repeat the same mistake" pattern, and without it a planning agent that fails once will fail the same way indefinitely. It touches both Calibration (learning what it does poorly) and Strategy (changing approach based on past failure) — you'll see this idea again in the replanning logic lesson 16 builds.
The cost table below tracks calls, tool use, and backtracking — a different axis from the Skills/Calibration/Strategy/Abstraction one this lesson opened with. Mapped onto that second axis: CoT and Self-Consistency only ever touch Skills. Self-Consistency's sample agreement is a first, crude hint of Calibration. Tree of Thoughts is the first to reach Strategy, because it explores before committing. Reflexion touches both Calibration and Strategy through its failure memory. Only Planner-Executor reaches all four, because only it separates deciding what to do from doing it.
Plan-and-Solve prompting asks for the plan and the execution in a single call: "first devise a plan, then execute each step." It separates planning from execution logically, which cuts missing-step errors versus diving straight into a task — but plan and execution still share one context window and one model call, so the model cannot revise the plan once it has started executing. Use it for single-session tasks of five to eight steps unlikely to need revision; anything that might fail mid-task needs the full split below instead.
Planner-Executor is where all of the above is heading, and the only entry in this table that separates planning into its own stage, with its own model call, capable of revising the plan when execution reports a failure back. It's named here as the destination of the taxonomy, not built here — that's lesson 16's job.
| Technique | LLM Calls | Tool Use? | Backtracking? | Best For |
|---|---|---|---|---|
| CoT | 1 | No | No | Quick reasoning boost |
| Self-Consistency | 5-40 | No | Statistical | Reducing random errors |
| Tree of Thoughts | 10-100+ | Optional | Yes (search) | Hard puzzles, strategy |
| ReAct | 3-15 | Yes | No | Short tool-grounded tasks |
| Reflexion | 3-15 x episodes | Yes | Across episodes | Iterative improvement |
| Plan-and-Solve | 1-2 | Optional | No | Medium-complexity tasks |
| Planner-Executor | 2+ per step | Yes | Yes (replan) | Long-horizon agentic tasks |
Don't memorize the names — memorize the two questions that place any technique on this spectrum. Does it consider more than one candidate path before committing (that's the Strategy axis)? And does it persist state or a plan across more than one model call (that's the Abstraction and replanning axis)? CoT answers no to both. Planner-Executor answers yes to both. Everything else sits somewhere in between, and now you know where to look.
What comes next
This lesson stayed at the level of naming and ranking — it did not build anything. Lesson 15 takes the ReAct row from the table above and builds it by hand: a real Thought/Action/Observation loop, parsed out of raw model text with a regex, run against two tools, so you can see exactly why the loop is linear and exactly where it starts to strain. That fragility is deliberate groundwork — it's what makes native tool calling, and eventually the full Planner-Executor split in lesson 16, look like a fix for a specific, felt problem instead of new syntax to memorize.
Build the ReAct loop from scratch — Thought, Action, Observation, regex-parsed by hand — and see exactly why native tool calling exists.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
