Reasoning Frameworks: Chain-of-Thought and Task Decomposition

Chain-of-thought (CoT) is a technique that elicits explicit, step-by-step intermediate reasoning from a model before it commits to a final answer, rather than having the model jump directly from a question to a response. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md): the domain's own framing states that CoT "elicits explicit step-by-step reasoning, improving multi-step problems" — the improvement is the entire justification for the technique existing, and it is worth understanding mechanically why forcing the intermediate steps into the output helps rather than just adding length for its own sake.

Why writing the steps out actually helps

A model generates its answer one token at a time, and each new token is produced conditioned on everything generated so far, including the model's own prior output within the same response. When a model is asked a multi-step arithmetic or logic problem and instructed to answer directly with no intermediate reasoning, it has to arrive at the correct final token sequence without any of the intermediate results ever becoming part of what it is conditioning on — effectively attempting the whole multi-step computation "in its head" in one pass. When a model is instead prompted to work through the problem step by step, each intermediate step it writes becomes additional context that every subsequent token can attend to, so the model is no longer solving the whole problem in one leap; it is solving one step, seeing that step's result as text it can now condition on, and solving the next step from there. This is why CoT reliably helps specifically on tasks with several dependent steps — arithmetic word problems, multi-hop questions, logic puzzles, constraint satisfaction — where an error anywhere in an unstated intermediate calculation would otherwise be invisible and uncorrectable, but becomes visible, and sometimes self-correctable, once it is written down as an explicit step.

L1 — Intuition

Chain-of-thought is the difference between doing long division in your head and doing it on paper. Attempted entirely in your head, a multi-digit division problem is easy to botch at some hidden intermediate step with no way to catch the error before it propagates into a wrong final digit. Worked on paper, each intermediate remainder is written down, visible, and available to check against as you proceed — the paper does not make you smarter, it just gives you (and anyone checking your work) a place to catch an error before it compounds.

L2 — Mechanism

Practically, CoT is usually elicited with an instruction ("think step by step," or a few-shot example showing worked intermediate reasoning before the final answer) that shapes the model's output to include that reasoning explicitly, rather than jumping to a bare answer. The model then generates its reasoning and its answer as one continuous sequence, with the reasoning portion generated first and the final answer conditioned on it. Nothing about this changes the model's weights or its underlying capabilities — CoT is a prompting and generation-shape technique, not a training technique — but it does change what intermediate computation the model gets to condition on before committing to a final token sequence, and that alone is enough to produce a measurable accuracy improvement on the class of tasks named above.

L3 — The exam-relevant edge case: what CoT does not give you

It is worth being precise about the limits of chain-of-thought, because a scenario question can test whether you understand what CoT is not, not just what it is. CoT improves accuracy on tasks that genuinely benefit from explicit intermediate steps; it does nothing by itself to connect the model to the outside world, to let it verify a fact against a real data source, or to let it take an action and observe a real result. A model reasoning step by step about "what the weather in Austin probably is" with no tool access is still just generating plausible-sounding text — CoT gives it a more careful-looking process for producing that text, not a way to check it against reality. Connecting reasoning to real actions and real observations is what ReAct adds on top of CoT-style reasoning, which is precisely why the two are related but not interchangeable, and it is why this lesson treats CoT as a reasoning framework in its own right rather than assuming it already includes the tool-use piece.

Task decomposition is a distinct reasoning framework: breaking a goal into smaller sub-tasks that an agent tackles sequentially, rather than attempting the entire goal in one undifferentiated pass. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) describes task decomposition directly as "the backbone of multi-step planning" — a phrase worth reading carefully, because it is making a specific structural claim: task decomposition is not itself the whole of planning (this module's next lesson, M5-04, catalogs four other planning directions beyond it), but essentially every one of those other planning directions still needs some sub-task structure to operate over, which is what makes decomposition foundational rather than merely one option among equals.

Why "break it into pieces" is a reasoning framework, not just common sense

It is tempting to treat task decomposition as too obvious to deserve a name — of course you break a big task into smaller pieces. The reason it earns its own framework status is that how a goal gets split matters enormously for whether the resulting plan actually works, and getting the split wrong is a specific, recurring failure mode rather than a rare edge case. A goal decomposed into sub-tasks that are too coarse leaves the agent facing the same "solve it all in one leap" problem CoT exists to avoid, just one level down. A goal decomposed into sub-tasks that are too fine-grained, or that do not actually cover everything the original goal required, produces a plan that looks thorough but silently drops requirements between the cracks of its own sub-tasks. Task decomposition, done well, requires the sub-tasks to be genuinely sequential — each one's output feeding the next, or at minimum not depending on information only a later sub-task will produce — and to jointly cover the original goal without gaps or unnecessary overlap.

A worked decomposition, traced step by step

Consider a goal: "Produce a one-page competitive summary of three named products for a sales team, due today." Decomposed naively, an agent might try to produce the entire summary in one generation pass, reasoning about all three products' features, pricing, and positioning simultaneously — which is exactly the same "solve it all in one leap" problem CoT is built to avoid, just at the level of an entire multi-part deliverable rather than a single arithmetic step. Decomposed properly, the goal splits into sequential sub-tasks: (1) gather the current feature set and pricing for each of the three products individually, (2) identify the two or three dimensions that actually differ meaningfully across them, (3) draft a one-paragraph positioning statement per product against those dimensions, (4) assemble the three paragraphs into the one-page format the sales team expects. Each sub-task's output becomes an input the next sub-task needs — step 2 cannot run meaningfully before step 1's data exists, and step 4 needs all three of step 3's drafts — which is what makes this decomposition genuinely sequential rather than an arbitrary list of things that happen to relate to the same goal.

Because both techniques involve "breaking something into steps," it is easy to conflate them, and the exam's phrasing sometimes leans on exactly that ambiguity. The distinction that resolves it: chain-of-thought breaks a single reasoning process into explicit intermediate steps within one generation, aimed at getting one correct answer to one question or problem. Task decomposition breaks an entire goal into separate sub-tasks that may each involve their own reasoning, their own tool calls, and their own generation passes, aimed at producing a complete multi-part deliverable rather than a single answer. A CoT-elicited response to "what is 47 times 23, worked step by step" is one generation, with intermediate arithmetic steps visible inside it, answering one question. The competitive-summary example above is four separate sub-tasks, each of which might itself use CoT-style reasoning internally, but the decomposition into those four sub-tasks is happening at a different level entirely — above the level of any single generation, at the level of how the overall goal gets structured into a plan.

This is also why task decomposition is correctly described as the backbone of multi-step planning while CoT is described as a reasoning technique that improves accuracy on multi-step problems: decomposition is about structuring what gets attempted and in what order, and CoT is about how carefully any one of those attempts gets reasoned through once it starts.

[GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) states plainly that these ideas "connect to Domain 1's ReAct: ReAct wraps reasoning (CoT-style) around tool actions" — and that single sentence is the entire relationship this lesson needs to establish, because M1-03 already covers ReAct's Thought/Action/Observation loop in full and this lesson has no business re-deriving it. What is worth making explicit here, briefly, is why that connection is phrased as "wraps... around" rather than "replaces" or "is the same as": ReAct's Thought step is functionally a chain-of-thought step — explicit intermediate reasoning, written out before an action is taken — but ReAct does not stop at reasoning the way plain CoT does. It takes that reasoning, commits to an Action based on it, and then folds a real Observation from that action back into the next round of reasoning, which is a capability plain CoT never had on its own, because plain CoT has no action step and nothing to observe.

Read this way, ReAct is best understood as a worked example of composing frameworks rather than as a third, independent item to memorize alongside CoT and task decomposition: it demonstrates one concrete way of applying CoT-style reasoning (the Thought) as one component inside a larger loop that also does something CoT alone cannot — actually touch the outside world and adjust based on what comes back. A scenario question asking you to name "the reasoning technique ReAct uses internally" is asking about CoT; a scenario question asking you to name "what ReAct adds beyond CoT" is asking about the action-and-observation loop M1-03 covers, and conflating the two is a fast way to answer a well-posed question incorrectly.

How decomposition and ReAct typically combine in practice

Because task decomposition determines what an agent's sub-tasks are and ReAct determines how a single sub-task that needs tool access actually executes, the two commonly nest: a decomposition step produces a sub-task like "look up this customer's current order status," and that sub-task, rather than being solved with a bare CoT pass, is handed to a ReAct-style loop because it genuinely requires touching an external system and reading back a real result. Not every sub-task needs this — a sub-task like "summarize these three paragraphs" needs no tool access and no observation loop, so a plain generation (with or without CoT) is the right amount of machinery for it. Reaching for ReAct on a sub-task that never needed to touch the outside world adds latency and complexity with no corresponding benefit, and reaching for a bare CoT pass on a sub-task that genuinely needs a real, checkable observation leaves the agent reasoning about a fact it never actually verified. Matching the right tool to each sub-task — plain generation, CoT, or a full ReAct loop — is itself a decomposition-time decision, which is one more reason decomposition is described as the backbone the rest of an agent's reasoning apparatus gets organized around, rather than one technique competing for the same slot as CoT or ReAct.

To make the distinction concrete rather than definitional, trace one task — "plan and execute a three-city research trip itinerary within a fixed budget" — through three different reasoning setups.

Setup 1: No CoT, no decomposition -- single direct generation.
  Prompt: "Plan a 3-city research trip within $2,400. Give me the final itinerary."
  Model output: a plausible-looking itinerary with costs that do not actually sum to
  $2,400 when checked, because no intermediate arithmetic was ever made explicit or
  checkable, and no sub-task boundaries existed to catch a dropped constraint.

Setup 2: CoT only, no decomposition.
  Prompt: "Plan a 3-city research trip within $2,400. Show your reasoning step by step,
  then give the final itinerary."
  Model output: explicit running-total arithmetic is now visible and the final budget
  sum is more likely to be internally consistent, but the plan is still produced as one
  continuous pass -- if the model front-loads spending on city 1 and only realizes deep
  into its reasoning that city 3 needs more than what is left, there is no structural
  checkpoint forcing it to revisit city 1's allocation.

Setup 3: Task decomposition, with CoT inside each sub-task.
  Sub-task A: "List the 3 cities and a fixed per-city budget ceiling that sums to $2,400."
  Sub-task B (for each city, run separately): "Within this city's ceiling, plan lodging,
  transit, and meals, reasoning step by step."
  Sub-task C: "Assemble the three city plans into one itinerary; flag any city over its
  ceiling."
  Model output: each sub-task's output is a separate, checkable artifact -- sub-task A's
  three ceilings can be verified to sum to $2,400 before any city planning even begins,
  and sub-task C has an explicit checkpoint whose entire job is catching an overrun
  before it reaches the final itinerary.

Constructed scenario — the dollar figures and city count are illustrative, not drawn from a real itinerary. The progression across these three setups is the lesson in miniature: no structure leaves both the arithmetic and the sub-task boundaries invisible and unchecked; CoT alone makes the arithmetic visible but leaves the sub-task boundaries nonexistent; decomposition with CoT inside each piece makes both visible, which is why production agent designs for genuinely multi-part goals lean on both together rather than treating them as alternatives.

A practical use of keeping CoT and task decomposition distinct is that they point to different fixes when an agent produces a wrong result, and reaching for the wrong fix wastes an iteration cycle without addressing the real problem. The diagnostic question worth asking first is where, structurally, the failure happened: inside a single reasoning pass, or across the boundary between two sub-tasks.

The last row is worth sitting with specifically because it is the cleanest illustration of why ReAct is a composition rather than a redundant third framework: some failures are not reasoning failures or planning-structure failures at all, they are grounding failures, and grounding is the one thing this lesson's two frameworks were never designed to solve by themselves.

Cognition, Planning, and Memory carries 10% of the NCP-AAI blueprint, and objective 5.2 specifically names applying "reasoning frameworks (chain-of-thought, task decomposition)" as its own tested skill, distinct from the memory objective before it (5.1) and the planning-strategies objective after it (5.3) that M5-04 covers in full. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) frames task decomposition explicitly as "the backbone of multi-step planning" and calls out the ReAct connection directly, which signals the two most likely question shapes: one that asks you to classify a described reasoning process as CoT, task decomposition, or neither, and one that asks you to identify what ReAct is doing at a given moment — reasoning (CoT) or acting-on-an-observation (the loop mechanism M1-03 owns).

Expect a distractor pattern that offers "ReAct" as an answer to a question that is actually asking about plain CoT, or vice versa — testing whether you can tell "the reasoning technique used inside a step" apart from "the loop that wraps reasoning with action and observation." The fix for that distractor pattern is the same one this lesson has built toward throughout: ReAct's Thought is CoT; ReAct as a whole is more than CoT, because it adds Action and Observation, and a question about which of those specific ingredients is present in a described scenario is testing precision, not just recognition of the word "ReAct."

⭐ THE EARNED INSIGHT

"ReAct uses chain-of-thought" is true and also the exact sentence that causes people to answer the wrong question under time pressure — because it invites treating ReAct as CoT with extra steps bolted on, when the actual relationship is a composition of two frameworks operating at different jobs: CoT makes one reasoning pass show its work, and Action-plus-Observation is the only thing in this entire lesson that ever touches ground truth outside the generation itself. A pile of careful, explicit reasoning steps that never checks anything against reality is still just a longer guess; the moment a real observation enters the loop is the moment the framework stopped being CoT, whatever it still visibly contains.

Chain-of-thought is explicit, step-by-step reasoning generated before a final answer, entirely within one generation, with no action taken on the outside world and nothing observed back. ReAct uses that same kind of explicit reasoning as its Thought step, but wraps it inside a loop that also takes a real Action and folds a real Observation from that action back into the next round of reasoning — a capability plain chain-of-thought does not have on its own, since it never touches anything outside the generation itself. ReAct's mechanism, including its Thought/Action/Observation cycle, is covered in full in this cert's M1-03.

Because nearly every other planning approach — selecting among candidate plans, calling an external planning tool, revising a plan through reflection, or drawing on stored memory to inform a plan — still needs some sub-task structure to operate over, and task decomposition is what produces that structure. It is foundational in the sense that the other planning directions this module's next lesson catalogs largely build on top of a decomposition rather than replacing the need for one, which is why it is treated as the backbone rather than as one option among five equals.

No — chain-of-thought, in the sense this lesson uses it, is a prompting and generation-shape technique rather than a training requirement: an instruction or a few-shot example that shapes the model's output to include explicit intermediate steps before a final answer, applied at inference time to a general-purpose model. ⚠️ UNVERIFIED — some model families are additionally trained or fine-tuned to produce extended internal reasoning by default, which is a related but separate development from the base CoT prompting technique the domain-5 source material describes, and the source material does not itself distinguish the two, so treat "CoT requires special training" as an unconfirmed claim rather than something this lesson's ground truth supports either way.

Check two things: whether each sub-task is genuinely sequential, meaning it depends only on information already available from an earlier sub-task rather than assuming information a later sub-task will produce, and whether the full set of sub-tasks jointly covers every requirement of the original goal with no gaps. A decomposition that fails the first test tends to stall or produce inconsistent intermediate results; a decomposition that fails the second test tends to produce a plausible-looking final output that is silently missing something the original goal actually required.

• Chain-of-thought elicits explicit intermediate reasoning within a single generation, improving accuracy on multi-step arithmetic, logic, and multi-hop problems by making each step something the model can condition on.
• Task decomposition splits an entire goal into sequential sub-tasks and is described as the backbone of multi-step planning — a different operation, at a different level, than CoT's within-one-generation reasoning.
• ReAct's Thought step is a CoT-style step; ReAct as a whole adds Action and Observation on top of it, which is why it is a composition of frameworks rather than a third independent one.
• A well-formed decomposition requires sub-tasks to be genuinely sequential and to jointly cover the original goal without gaps — getting either wrong is a specific, recurring failure mode, not a rare edge case.
• CoT improves the odds of a correct answer; it does not guarantee one, and it does nothing on its own to connect an agent to the outside world the way an action-and-observation loop does.
• On the exam, expect scenario questions that ask you to classify a described process as CoT, task decomposition, or a ReAct-style composition of the two with action and observation added — precision about which specific ingredient is present is what these questions test.

This lesson treated task decomposition as the backbone that planning builds on, without yet cataloging the other ways an agent can plan on top of it.

Next: M5-04 lays out the full set of five planning directions — Task Decomposition, Plan Selection, External Module, Reflection, and Memory — and works through why reciting only decomposition as "the" planning method is this domain's standing trap.