Planning Strategies: The Five Directions for Agent Planning

[GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) attributes this five-direction taxonomy to "the LLM-agent planning survey (Huang et al., 2024)," and frames it as the answer to objective 5.3's charge of engineering "planning strategies for sequential, multi-step decisions." Notice the structural shape of this list before going any further: it is not five ways of doing the same thing — it is five different moments in a planning process where a distinct kind of work happens. Task Decomposition happens when a goal first gets structured. Plan Selection happens when more than one structuring is possible and one has to be chosen. External Module happens when the agent's own reasoning is not trusted (or not sufficient) to produce or check the plan alone. Reflection happens after execution has already produced some result. Memory happens whenever a past experience is available to inform any of the other four. Keeping straight when each direction operates is the fastest route to classifying a described scenario correctly.

Plan Selection means generating multiple candidate plans for the same goal and choosing among them, rather than committing to the first plan a single reasoning pass happens to produce. The premise behind this direction is that a single planning attempt, especially for a genuinely ambiguous or high-stakes goal, is not guaranteed to be the best available plan — and if the cost of generating a few alternative plans is low relative to the cost of executing a bad one, generating several and comparing them is worth the extra reasoning.

L1 — Intuition

Plan Selection is asking three colleagues to independently sketch an approach to the same problem, then picking the strongest sketch — or the strongest pieces of each — rather than committing to whichever colleague happened to speak first. The value is not that any one sketch is guaranteed correct; it is that seeing several candidate approaches side by side surfaces tradeoffs a single pass would never have made visible.

L2 — Mechanism

An agent implementing Plan Selection generates more than one candidate plan for the same goal — sometimes by prompting for multiple distinct plans directly, sometimes by sampling the planning step several times and treating the resulting variations as candidates — and then applies some selection criterion to choose among them: an estimated cost, a predicted likelihood of success, a check against known constraints, or in some designs a further model call asked specifically to judge which candidate looks strongest. The selected plan is then the one actually executed; the discarded candidates are not wasted reasoning so much as the price paid for a better-informed choice than a single plan would have offered.

L3 — The exam-relevant edge case: Plan Selection happens before execution, Reflection happens after

The distinction worth holding onto precisely, because it is the specific pairing the source material calls out as a common distractor-vs-correct trap, is when multiple plans enter the picture. Plan Selection generates its candidates before any of them is executed and chooses among options that have not yet been tried. Reflection, covered below, revises a plan based on outcomes that have already happened — it is inherently a post-execution operation, informed by what actually occurred, not by a pre-execution comparison of untested alternatives. A scenario describing an agent that drafts three approaches and picks the best-looking one before doing anything is Plan Selection. A scenario describing an agent that tried an approach, watched it partially fail, and adjusted is Reflection. Both involve "more than one version of a plan," which is exactly why they get confused, and exactly why the timing — before execution versus after outcomes are known — is the test that actually resolves it.

External Module means using an external planner or tool to produce or verify the plan, rather than relying solely on the agent's own language-model reasoning to both generate and validate it. This direction exists because an agent's own free-form reasoning, however good at producing plausible-sounding plans, is not always the most reliable or most efficient way to solve a planning problem that has a well-defined structure a specialized tool already handles better.

L1 — Intuition

External Module is calling a routing engine to compute the actual shortest path between two addresses rather than asking a language model to reason its way to one from general knowledge of the map. The language model is good at deciding that a route is needed and at incorporating the result into a broader plan; it is not the right tool for computing the route itself once a purpose-built tool exists that can do that exactly and quickly.

L2 — Mechanism

An agent using this direction identifies that some part of its planning problem matches a domain a specialized external system is built for — a classical planning algorithm, an optimization solver, a scheduling engine, a symbolic verifier — and delegates that part of the plan's construction or verification to that system, treating its output as an input to the agent's overall plan rather than generating that piece through free-form reasoning. Verification, specifically, is worth calling out as its own valid use of this direction even when the plan itself was generated by the agent: an external module can check a generated plan against hard constraints (a budget ceiling, a scheduling conflict, a physical feasibility check) that a language model's own reasoning might state confidently but get wrong, giving the agent a second, more reliable signal about whether a plan is actually sound before committing to executing it.

L3 — The exam-relevant edge case: External Module is not the same as ordinary tool use inside a sub-task

It is easy to conflate "the agent used an external tool" in general with the External Module planning direction specifically, but the distinction is about what the tool is being used for. A ReAct-style agent calling a calculator or a search API mid-task, as part of executing one sub-task within an already-decided plan, is ordinary tool use — the kind M5-03's discussion of ReAct already covers. External Module, in the planning-taxonomy sense, refers specifically to using an external system to produce or verify the plan itself — the structure of what should happen and in what order — not to execute one already-decided step within it. A scenario where an agent calls a search tool to find a fact needed for one step is tool use inside execution. A scenario where an agent calls a dedicated planning or scheduling system to generate or check the sequence of steps is External Module. Both are "the agent used a tool," which is exactly why the distinction has to be made on function, not on the mere presence of a tool call.

Reflection means revising a plan based on outcomes or feedback — taking what actually happened when some part of a plan was executed and using it to adjust the plan going forward, rather than executing the original plan to completion unmodified regardless of what results come back along the way. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) names Reflection as a planning direction distinct from Plan Selection specifically because the source material calls out this exact pair as a common distractor-vs-correct confusion, which is the strongest signal available that precision on this boundary is worth the effort.

L1 — Intuition

Reflection is a hiker checking the map again after taking a wrong turn, rather than a hiker who compared three possible routes before setting out and never looked at the map again once walking. The first behavior only happens because something already went differently than expected; the second behavior happens entirely in advance of any steps being taken.

L2 — Mechanism

An agent implementing Reflection executes some portion of its plan, observes the result, and compares that result against what was expected. When the two diverge — a sub-task failed, produced an unexpected output, or revealed new information the original plan did not account for — the agent revises the remaining plan in light of that divergence, rather than mechanically continuing to execute the original sequence as if nothing had happened. This is structurally close to ReAct's Observation-into-next-Thought loop at the level of a single action, but Reflection as a planning direction operates at the level of the plan itself: it is not just "what should the next action be," it is "does the plan as a whole still make sense given what just happened, or does the plan itself need to change."

L3 — The exam-relevant edge case: Reflection needs an outcome to react to; it cannot happen before execution starts

Because Reflection is defined by reacting to an outcome, a described agent behavior that revises a plan with no execution having occurred yet cannot be Reflection, no matter how much it looks like "reconsidering a plan" on the surface — that scenario, generating and comparing options before committing, is Plan Selection instead. The single fastest test for telling these two apart on the exam: ask whether anything has actually been tried yet. If yes, and the plan changed in response to what happened, it is Reflection. If no, and multiple options are simply being compared before any of them runs, it is Plan Selection.

Memory, as a planning direction, means using stored experience to inform planning — drawing on what an agent has retained from past situations, of the kinds M5-02 catalogs in full, to shape the plan being constructed now, rather than planning from the current situation's description alone with no reference to anything that came before it.

L1 — Intuition

Memory as a planning input is consulting your own notes from a similar project before starting a new one, rather than starting entirely from first principles every single time as though no comparable situation had ever occurred before.

L2 — Mechanism

Concretely, this direction means a planning step retrieves relevant stored experience — an episodic record of a similar past situation and what happened, a semantic rule generalized from many such situations, or a procedural skill refined through repeated practice, using the vocabulary M5-02 already established — and incorporates it into the plan under construction, rather than generating the plan from the current goal description in isolation. An agent planning a new customer's return request that first retrieves a semantic rule ("wrong-size apparel returns under $150 do not need manager approval") is using Memory as a planning direction in exactly this sense: the plan it constructs for the current situation is shaped by something retained from before this situation existed.

L3 — The exam-relevant edge case: Memory as a planning direction is not a fourth memory category

It would be a mistake to read "Memory" showing up as one of the five planning directions and conclude it introduces some new memory type beyond the five M5-02 already covered. It does not — Memory, here, names the use of any of those existing categories (episodic, semantic, or procedural, retrieved from whichever long-term store holds them) as an input to a planning decision, not a new kind of storage. The taxonomy question ("what kind of memory is this?") and the planning-direction question ("is this planning approach using memory as an input?") are two different questions about the same underlying stored content, and a scenario can test either one — recognizing which question is actually being asked is what keeps this lesson's material and M5-02's material from blurring into each other.

Consider an agent tasked with resolving a customer's damaged-item complaint, tracing how all five directions can appear within a single planning episode rather than as five separate, unrelated agents.

Step 1 (Memory): Retrieve semantic rule from long-term store —
  "Damaged-item complaints under $100 qualify for auto-refund without escalation."
  Retrieve episodic record — a similar complaint 6 weeks ago that WAS auto-refunded
  successfully with no follow-up dispute.

Step 2 (Task Decomposition): Split the goal into sub-tasks --
  (a) confirm item value against the $100 threshold, (b) issue refund if under threshold,
  (c) log the resolution, (d) send confirmation to customer.

Step 3 (Plan Selection): Two candidate orderings for (b) and (c) are generated --
  Candidate 1: issue refund, then log.  Candidate 2: log first, then issue refund.
  Selection criterion: Candidate 2 chosen, because logging before the refund call means
  a failed refund attempt still leaves a record, rather than an unlogged refund existing
  with no corresponding record if the logging step failed afterward.

Step 4 (External Module): Before issuing the refund, a separate constraint-checking
  service is called to verify the item's actual purchase value against the complaint --
  a numeric verification the agent's own reasoning is not trusted to get exactly right
  from unstructured complaint text alone.

Step 5 (Reflection): The refund call returns an error -- the customer's payment method on
  file has expired. The plan is revised: instead of the original refund-then-confirm
  sequence, the agent now inserts a new sub-task (request updated payment details) before
  the refund can proceed, because the outcome of step 4's attempted execution has changed
  what the remaining plan needs to include.

Constructed scenario — the dollar threshold, timing, and specific ordering are illustrative, not drawn from a real support system. Every one of the five directions did genuinely different work in this trace: Memory supplied prior experience before any structuring began, Task Decomposition gave the goal its shape, Plan Selection chose between two orderings of already-decomposed sub-tasks, External Module offloaded a verification the agent's own reasoning should not be trusted with alone, and Reflection revised the plan only after an actual execution attempt produced an unexpected result.

Because the exam tends to present one described behavior at a time and ask which direction it demonstrates, work through five short, isolated scenarios the way a question would present them.

Scenario A: An agent drafts a project plan by first listing every distinct piece of
work the project requires, in dependency order, before writing any of it.
  -> Task Decomposition. The goal is being structured into an ordered set of sub-tasks;
     nothing here compares multiple whole-plan candidates or reacts to an outcome.

Scenario B: An agent generates two entirely different overall approaches to the same
project and picks the one with the lower estimated total time, before starting either.
  -> Plan Selection. Multiple candidate plans, compared before execution begins.

Scenario C: An agent calls a dedicated scheduling-optimization service to determine the
exact ordering of eight tasks against three shared resources, rather than reasoning its
way to an ordering directly.
  -> External Module. A specialized external system produces the plan's structure.

Scenario D: An agent's first attempt at the project plan assumed a resource would be
available on Tuesday; once execution reveals the resource is unavailable until Thursday,
the agent revises the remaining schedule accordingly.
  -> Reflection. The revision is a direct reaction to an outcome from an already-attempted
     step, not a pre-execution comparison.

Scenario E: Before drafting anything, the agent retrieves a record of a similar project
from four months ago and reuses its resourcing pattern as a starting point.
  -> Memory. Stored experience is informing the plan under construction, prior to and
     independent of any decomposition, selection, or reflection step.

Constructed scenario — illustrative only. Notice that A and E can look similar on the surface (both happen "before" much else occurs) but are answering different questions: A is about structuring the current goal, E is about importing something from outside the current goal entirely. The same is true of B and D: both involve more than one version of a plan, but B's comparison happens with nothing yet tried, and D's revision happens only because something already was.

Cognition, Planning, and Memory carries 10% of the NCP-AAI blueprint, and objective 5.3 — engineering "planning strategies" for sequential, multi-step decisions — is where this five-direction taxonomy lives. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) states the trap directly: "Reciting only task decomposition as the planning method" is the domain's single most flagged failure, with the source material naming Reflection and Plan Selection specifically as "common distractor-vs-correct pairs" — a direct signal that these two, more than the other three, are where the exam concentrates its hardest scenario items.

Expect a question that names a planning behavior and offers all five directions as options, exactly one of which fits — and expect the wrong options to include at least one adjacent, easily-confused direction rather than four obviously wrong ones. The two fastest resolving tests this lesson has built are worth having ready: for a Reflection-vs-Plan-Selection ambiguity, ask whether anything has actually been executed yet; for an External-Module-vs-ordinary-tool-use ambiguity, ask whether the tool is producing or verifying the plan's structure itself, or just executing one step that a decomposition already decided needed to happen.

⭐ THE EARNED INSIGHT

Four of the five directions are genuinely easy to name once you have seen the list; the reason the trap persists anyway is that Task Decomposition is the only one of the five that is visible from the very first moment a plan exists, while Plan Selection, Reflection, and Memory are only visible if you ask what happened before the current sub-task list was settled or after something in it was tried. A scenario question is rarely testing whether you know the five names — it is testing whether you looked for a direction outside the one direction that happens to be looking back at you from the first line of the plan.

Naming which direction a given piece of planning behavior belongs to is a classification exercise, and like the memory taxonomy it sits alongside, classification is not the same as a design recipe. Knowing that Plan Selection is the right label for "compare candidates before executing" does not tell you how many candidates are worth generating, or what selection criterion should decide among them — those remain engineering judgment calls specific to the goal, the cost of generating extra candidates, and how much a wrong choice would cost if executed. Similarly, knowing that Reflection is the right label for "revise after an outcome" does not specify how much of the remaining plan should be revised versus how much should be preserved unchanged; a minor deviation from expectations might warrant adjusting one sub-task, while a major one might warrant re-decomposing the goal from scratch. The five directions give you the vocabulary to say precisely what kind of planning work is happening at a given moment — they do not, by themselves, tell you how much of that work a given situation actually needs.

Task Decomposition, Plan Selection, External Module, Reflection, and Memory. Task Decomposition splits a goal into sub-tasks; Plan Selection generates multiple candidate plans and chooses among them before execution; External Module delegates producing or verifying the plan's structure to a specialized outside system; Reflection revises the plan based on outcomes once some part of it has actually been executed; and Memory uses stored past experience to inform the plan being constructed. Reciting only Task Decomposition, though it is the most familiar of the five, is the domain's most commonly flagged exam trap.

Plan Selection compares multiple candidate plans before any of them has been executed, choosing among untested options. Reflection revises a plan after execution has already produced some outcome, reacting to what actually happened rather than comparing options in advance. Both involve more than one version of a plan existing at some point, which is why they are frequently confused, but the timing relative to execution — before versus after something has actually been tried — is what distinguishes them and is the fastest way to resolve a scenario question testing this pair.

No. External Module refers specifically to using an external system to produce or verify the plan's own structure — the sequence and ordering of what should happen — not to executing one step of an already-decided plan. An agent calling a search tool or a calculator to complete a single sub-task that a decomposition already assigned is ordinary tool use inside execution, not the External Module planning direction. The distinguishing question is whether the external system is shaping or checking the plan itself, or simply carrying out a step the plan already specified.

Sometimes, and recognizing this is part of applying the taxonomy correctly rather than mechanically. A step that retrieves a past episode and, in the same motion, uses it to decide between two candidate orderings is doing Memory and Plan Selection together — the retrieval supplies the input, and the comparison-and-choice is the separate operation the retrieved input feeds into. The five directions name distinct kinds of work, not five mutually exclusive labels that every planning moment must sort into exactly one bucket; a scenario question typically isolates one direction cleanly by describing only one kind of work happening, but real planning episodes, like the worked example in §7, routinely chain several directions together in a single coherent process.

• The five planning directions are Task Decomposition, Plan Selection, External Module, Reflection, and Memory — reciting only Task Decomposition is the domain's most commonly flagged trap.
• Plan Selection compares untested candidate plans before execution; Reflection revises a plan after execution has produced an outcome — timing relative to execution is what separates them.
• External Module means delegating the plan's own structure or verification to an outside system, not merely calling a tool to execute one already-decided step.
• Memory as a planning direction reuses the existing memory taxonomy (M5-02) as an input to planning; it does not introduce a sixth memory category.
• A single planning episode can use several or all five directions in sequence, each doing distinct work at a distinct moment — they are tools applied as needed, not a mandatory checklist.
• On the exam, expect a scenario naming a planning behavior with one correct direction among five options, and expect the hardest distractors to pair Plan Selection against Reflection or External Module against ordinary tool use.

This lesson has cataloged how a plan gets structured, chosen, checked, revised, and informed by experience. What has not yet been addressed is where all of that state actually lives while a multi-step task is in progress — the sub-tasks already completed, the plan as currently revised, the memory already retrieved.

Next: M5-05 covers exactly that: stateful orchestration as the layer where memory and planning meet, holding the state both subsystems read and write across a task's full lifetime.