Ask an agent to do something non-trivial and, before it calls a single tool, it has to answer a quieter question first: what, exactly, should it do, and in what order? That question is planning, and it is a different concern from the loop that executes the plan once it exists. The loop is the machinery that keeps a multi-step process running, recovers from errors, and knows when to stop. Planning is the cognition that decides what the steps should be in the first place. An agent can have a flawless loop and still fail constantly if its planning is bad, because a beautifully engineered execution mechanism will faithfully carry out a plan that was wrong from the start.
This distinction matters more than it might seem. Most of the attention in agent design goes to the loop, the tools, and the prompt, and planning is often treated as something the model just does, an emergent property of a capable enough language model that needs no separate engineering. Sometimes that is true. For a great many tasks, however, the difference between an agent that succeeds and one that spins its wheels, backtracks constantly, or confidently pursues the wrong sub-goal comes down entirely to how it plans: whether it commits to a full plan too early, whether it notices when the world has changed and its plan no longer fits, whether it decomposes a large goal into pieces that are actually independent, and whether it can tell a good plan from a bad one before spending the budget to find out the hard way. This is a practical tour of that layer: the patterns agents use to decide what to do next, when each pattern is the right tool, and where planning tends to go wrong.
Two kinds of tasks, and why the difference matters
Before reaching for any planning technique, it is worth asking whether the task needs one at all. Some tasks have a known, fixed shape: fetch the record, transform it, write the summary, done. The sequence of steps does not depend on what happens along the way, and the most reliable way to handle it is a straight-line workflow, a fixed sequence of calls with no branching decision about what comes next. There is no planning problem here because there is nothing to plan; the plan is the code.
Other tasks are open-ended in a way that makes the sequence of steps genuinely unknowable in advance. Debugging a failing test might take two steps or twenty, depending on what the first investigation turns up. Researching a claim might require one search or a dozen, depending on how contested the topic turns out to be. Planning as a distinct capability exists for exactly this second category, tasks where the path to the goal depends on information that is only available once you are partway down some path. The central design skill is recognizing which category a task falls into, because the most common planning failure is not a bad plan, it is planning for a task that never needed one, adding branching, replanning, and deliberation to something that would have been more reliable as a fixed sequence. The inverse mistake is just as common and just as costly: forcing an open-ended task into a fixed workflow, which produces a system that is fast and cheap right up until it meets an input the workflow did not anticipate, at which point it fails outright rather than adapting.
Planning exists for tasks where the right next step depends on what you learn from the step before. If the sequence is known in advance, you do not need a planner, you need a workflow.
Reactive planning: deciding one step at a time
The simplest planning strategy is not to plan ahead at all in any formal sense, but to interleave reasoning and acting one step at a time, observing the result of each action before deciding the next. This is the pattern most people mean when they talk about an agent reasoning about its next move: look at the current state, think briefly about what would help, take one action, look at the new state, and repeat. Popularized under the name ReAct, interleaving explicit reasoning traces with tool calls, this reactive style has become the default for a large share of production agents, and for good reason. It is simple to implement, it never commits to a long plan that reality might invalidate, and it lets every single decision benefit from the freshest possible information, namely the result of whatever just happened.
The weakness of pure reactive planning is exactly the flip side of its strength: because it never looks more than one step ahead, it can wander. An agent that decides its actions one at a time, with no persistent notion of an overall strategy, can end up pursuing locally reasonable but globally pointless sequences, checking one plausible lead after another without a structure that says when enough leads have been checked or which lead is most promising. It can also repeat itself, revisiting an approach it already tried three turns ago because nothing in its process forces it to remember and compare against a plan. Reactive planning shines on tasks that are short, where the next useful action is usually obvious from the current state, and where the cost of a wrong turn is small because the agent will notice and correct within a step or two. It struggles on tasks that are long, where the best next action depends on a strategy that spans many steps, and where wrong turns are expensive or hard to detect immediately.
Plan-then-execute: committing to a strategy up front
The alternative to deciding one step at a time is to generate a fuller plan before taking any action at all: enumerate the steps you expect to need, in order, and then execute them, consulting the plan rather than re-deriving the next step from scratch every turn. This plan-then-execute pattern trades the reactive approach's flexibility for something valuable in its place, namely coherence. A plan generated once, holding the whole task in view, is far less likely to wander than a sequence of locally reasonable decisions made one at a time, because the model that wrote the plan could see the entire shape of the problem when it made each choice, rather than only the sliver of state visible after the previous action.
Plan-then-execute also has a practical advantage that is easy to underrate: it produces an artifact you can inspect before any action is taken. A plan is legible in a way that a sequence of already-executed actions is not. You, or a human reviewer, or a validation step, can look at the plan and catch an obviously bad strategy, a missing step, or a dangerous action before the agent does anything in the world. For tasks where actions are expensive, slow, or hard to undo, having a reviewable plan up front is often worth more than the flexibility that reactive planning offers, because the review happens exactly once, cheaply, rather than being smeared across many individually-reviewed actions.
The obvious risk is that the world will not hold still long enough for a plan made in advance to remain correct. Information discovered during step three might reveal that steps four through seven no longer make sense, and a system that mechanically executes a stale plan regardless of what it has learned will complete the wrong task with great efficiency. This is why plan-then-execute in practice is almost never pure; it is nearly always paired with some mechanism for revising the plan when reality disagrees with it, which is the subject of the next section.
Replanning: the plan is a hypothesis, not a commitment
The healthiest way to think about an upfront plan is as a hypothesis about how the task will go, not a commitment to execute regardless of what happens. A well-designed planning agent generates a plan, executes the next step of it, and then explicitly checks whether the plan still makes sense given what that step revealed. Sometimes it does, and the agent proceeds to the following step unchanged. Sometimes it does not, a search turned up nothing, a file did not exist, an assumption baked into step four turned out to be false, and the agent needs to revise the remaining plan rather than execute it blindly. This replanning loop, plan, act, observe, reconsider the plan, repeat, captures most of the benefit of both pure strategies: the coherence of thinking ahead and the responsiveness of reacting to what is actually true.
Knowing when to trigger a replan is itself a design decision, and getting it wrong in either direction causes trouble. Replanning too eagerly, treating every minor surprise as grounds to throw out the plan and start over, is expensive and can produce the same wandering behavior that pure reactive planning suffers from, because a plan that gets rewritten every turn provides none of the stability it was meant to provide. Replanning too rarely, pressing on with a plan that quietly stopped fitting the situation several steps ago, produces the opposite failure, a confident agent marching through a strategy that no longer applies. The useful middle ground is to replan when a step's outcome contradicts an assumption the plan depended on, not merely when a step is slower or messier than expected, and to make that dependency explicit rather than leaving the model to guess whether a given surprise is significant enough to warrant reconsideration.
A plan is a hypothesis about how the task will go, checked and revised at each step, not a script executed blindly regardless of what is discovered along the way.
Decomposition: turning one goal into many smaller ones
Most non-trivial goals are not single actions but bundles of smaller goals, and a large share of what planning actually accomplishes is breaking the bundle apart into pieces small enough to execute directly. "Migrate the service to the new database" is not a step, it is a goal that decomposes into inventorying the current schema, designing the target schema, writing a migration script, testing it against a copy of production data, and executing it with a rollback plan ready. An agent that tries to act on the top-level goal directly, without decomposing it, tends to either freeze, because no single action accomplishes something that large, or take some plausible-looking but insufficient action and declare victory prematurely.
Good decomposition produces subtasks that are meaningfully smaller than the parent goal, each concrete enough to make direct progress on, and, importantly, as independent of each other as the problem allows. Independence matters because subtasks that secretly depend on each other in an order the decomposition did not capture will fail when executed out of that hidden order, and subtasks that are truly independent can, if your loop supports it, be pursued in parallel for a real reduction in latency. The decomposition itself deserves the same scrutiny as any other plan: an agent should be willing to look at its own breakdown of a goal and ask whether the pieces actually add up to the whole, whether any piece is still too large to execute directly and needs a further layer of decomposition, and whether the pieces are ordered correctly where order matters.
Decomposition can go wrong in a few recognizable ways. Pieces can be drawn at the wrong grain, either so large that each one is itself an unsolved planning problem, which just pushes the difficulty down a level without resolving it, or so small that the overhead of managing dozens of tiny subtasks exceeds any benefit from breaking the goal apart. Pieces can also be drawn with false independence, treating two subtasks as separable when the second in fact depends on an assumption the first was supposed to validate, which surfaces as a confusing failure when the second subtask runs and discovers the assumption does not hold. The discipline worth building into a decomposing agent is to state, for each subtask, what it depends on and what would have to be true for it to make sense, because that habit surfaces both the wrong-grain and false-independence failures before they cost you a wasted subtask.
Hierarchical planning: managers and workers
Decomposition scales naturally into a hierarchy once subtasks are themselves complex enough to need their own planning. A common and effective pattern is to split the system into a manager that holds the overall goal and decomposes it into subtasks, and one or more workers that each take a subtask and plan and execute it in detail without needing to see the full context of the parent goal. The manager thinks in terms of subtasks and their dependencies; the worker thinks in terms of tools and observations within the scope of one subtask. Neither layer needs to hold the whole problem in its head at once, which is exactly the property that lets the system take on tasks too large for a single flat plan to handle coherently.
The design questions that make or break a hierarchical setup are almost entirely about what crosses the boundary between manager and worker. The manager must hand the worker enough context to actually accomplish the subtask, typically the goal statement, any constraints, and any shared state the subtask depends on, without handing over so much that the worker is buried in irrelevant detail from the rest of the plan. The worker, in turn, must report back not just a final answer but enough information for the manager to judge whether the subtask actually succeeded and whether that success or failure changes anything about the remaining plan. A worker that reports only "done" gives the manager nothing to reason about when something later goes wrong, while a worker that reports its full internal trace defeats the purpose of the hierarchy by forcing the manager to process detail it was designed to be shielded from. Getting this interface right, a summary rich enough to inform the manager's next decision but not so rich it collapses the boundary, is most of the engineering effort in a hierarchical agent.
Budgets are the other place hierarchy needs deliberate design, for a reason that echoes nested execution loops: a worker that is individually well-behaved, with its own reasonable iteration cap, can still blow the overall budget if the manager invokes many workers, or invokes one worker many times. The remedy is the same as it is for nested loops, pass the remaining budget down explicitly from manager to worker rather than letting each layer assume it has the whole budget to itself, so the total cost across the hierarchy stays bounded no matter how many layers deep the plan goes.
Self-reflection: checking your own plan before and after
A capability that sits alongside decomposition and replanning, rather than replacing either, is having the agent explicitly critique its own plan or its own output before treating it as final. Rather than generating a plan and immediately executing it, a reflective agent generates a plan, then asks itself a pointed question: does this actually accomplish the goal, what could go wrong with it, is there a step missing? The same pattern applies after execution, generating an answer or completing a task, then checking the result against the original goal before reporting success, catching the case where every step technically ran but the accumulated result does not actually satisfy what was asked.
Self-reflection is valuable precisely because it costs an extra pass of reasoning to catch mistakes that a single pass tends to miss, since the same reasoning process that made a mistake is often blind to that mistake on the first attempt but can catch it when explicitly asked to check rather than to produce. The technique, sometimes formalized under names like Reflexion, works by feeding the critique back as input to another attempt, so the agent does not just notice a flaw but gets to act on the noticing. The cost is real, roughly doubling the reasoning spent on anything that gets reflected on, so the technique earns its keep most clearly on high-stakes or error-prone steps, a plan for an irreversible action, a final answer about to be delivered to a user, a piece of generated code about to be executed, rather than being applied uniformly to every minor decision an agent makes along the way.
The failure mode to watch for is reflection that is purely cosmetic, a critique step that always concludes the plan is fine because the prompt asking for criticism is vague or because the model has learned that agreeing with itself is the path of least resistance. Useful self-reflection needs the same specificity as any other prompt: ask concretely whether each step of the plan is necessary, whether any step is missing given the stated goal, and whether the plan's success criteria actually match what was asked, rather than asking the open and easily-satisfied question of whether the plan "looks good."
Search over reasoning paths: exploring more than one plan
Everything so far assumes the agent commits to one line of reasoning, one plan, one decomposition, and follows it, revising as needed but never running more than one candidate at a time. For tasks where the first plan the model generates is not reliably a good one, and where you can afford the extra cost, a different family of techniques explores multiple candidate reasoning paths and picks among them rather than committing to the first one produced.
Self-consistency is the simplest version: generate several independent reasoning attempts at the same problem, and take the answer that shows up most often among them, on the logic that a mistake in reasoning is less likely to be reproduced identically across several independent attempts than the correct answer is to be reached by more than one of them. Tree of Thoughts extends the idea by exploring partial reasoning paths as a branching tree rather than complete attempts in isolation, evaluating intermediate states and pruning the branches that look unpromising before they are carried to completion, which lets the search allocate more effort toward paths that are turning out well and abandon paths that are not, rather than paying the full cost of every branch to its end before comparing them.
These search-based techniques trade cost for reliability in a fairly direct way, since generating and evaluating several candidate paths costs some multiple of generating just one, and that multiple has to be worth it. They earn their cost on problems where a single reasoning attempt is meaningfully unreliable and where the problem has a checkable structure, arithmetic, logic, planning tasks with a verifiable goal state, that lets you actually judge which candidate path is better rather than merely different. They are usually not worth it for tasks a single well-prompted attempt already handles reliably, where the extra candidates mostly agree with each other and the added cost buys little.
Search over multiple reasoning paths spends extra compute to buy reliability, and it is worth spending exactly on the problems where a single attempt is not reliable enough and where you can actually check which candidate is better.
Uncertainty and knowing what you do not know
A plan is only as good as the assumptions it rests on, and a mature planning agent treats its own uncertainty as information rather than ignoring it. Some steps in a plan depend on facts the agent is confident about and some depend on facts it is only guessing at, and those two kinds of steps deserve different handling. A step built on a shaky assumption is a natural candidate for an early, cheap check, verify the assumption before investing in the steps that depend on it, rather than discovering three steps later that the whole branch was built on sand. This is a large part of why replanning triggers matter: they are, in effect, the mechanism by which uncertainty that was implicit in the plan gets resolved by evidence from execution.
Uncertainty also has an external face: telling a user or a calling system how confident the agent is in a plan, rather than presenting every plan with the same flat confidence regardless of how solid its foundations are. An agent that flags "this plan assumes the API supports pagination, which I have not yet confirmed" is giving whoever is relying on it useful information to act on, a chance to intervene before the plan runs rather than only after it has failed partway through. Surfacing uncertainty honestly is unglamorous compared to the planning techniques themselves, but it is often what separates a plan you can trust with a consequential task from one you can only use for something low-stakes enough that a wrong guess does not matter.
When planning helps and when it gets in the way
Every technique in this piece costs something, extra reasoning tokens, extra latency, extra complexity in the code that orchestrates it, and none of them are free wins to apply everywhere. Reactive, one-step-at-a-time planning is the right default for short tasks where the next useful action is usually obvious and mistakes are cheap to notice and correct. Plan-then-execute earns its keep on longer tasks where coherence across many steps matters and where having a reviewable artifact before any action happens is valuable in its own right. Decomposition is worth the overhead once a goal is genuinely too large for one plan to hold, and actively harmful when applied to a goal that was small enough to handle directly, since breaking a simple task into artificial pieces just adds coordination cost with nothing to show for it. Self-reflection and multi-path search are worth their extra cost on high-stakes or error-prone decisions and mostly wasted on the many decisions a system makes that are neither.
The practical skill is matching the planning technique to the task rather than reaching for the most sophisticated one available out of habit. A support agent answering a simple factual question does not need tree search over reasoning paths, hierarchical decomposition, and a reflection pass, it needs a fast, direct answer, and adding planning machinery to that path only slows it down and adds places for something to break. A code migration agent making irreversible changes to a production database absolutely benefits from an upfront plan, a review point before execution, and reflection on the plan's completeness, because the cost of extra deliberation there is trivial next to the cost of a wrong action. Knowing which situation you are in, cheap to be wrong versus expensive to be wrong, short task versus long one, is the actual judgment call, and it is a judgment call worth making explicitly rather than defaulting to whichever pattern was easiest to build first.
Common failure modes in agent planning
A handful of failure patterns account for most of the trouble planning agents run into in practice. Overcommitment is generating a detailed plan and executing it rigidly even after several steps have revealed that its assumptions no longer hold, the plan-then-execute failure of treating a hypothesis as a script. Underplanning is the opposite, reacting one step at a time on a task that actually needed a coherent strategy, producing an agent that wanders through locally plausible but globally directionless actions. Decomposition at the wrong grain produces subtasks that are either still too large to execute or so fragmented that coordinating them costs more than the decomposition saved. False independence treats subtasks as separable when a hidden dependency between them means executing them out of the assumed order breaks something, and it usually only surfaces as a confusing failure well after the plan looked fine on paper.
Cosmetic reflection is a self-critique step that exists in the code but never actually catches anything, because the prompt asking for criticism is too vague or too easy to satisfy with a reflexive "looks good." Runaway replanning is the thrashing failure where every minor surprise triggers a full reconsideration of the plan, so the agent never settles into executing anything and burns its budget rewriting a strategy instead of pursuing one. And silent uncertainty is a plan that rests on unverified assumptions the agent never surfaces, so a wrong guess buried in step two quietly propagates through every step built on top of it until the whole plan collapses at the end with no earlier warning that anything was shaky. Each of these has a direct remedy described earlier in this piece, replanning triggers for overcommitment, upfront plans for underplanning, dependency statements for false independence, and specific rather than open-ended reflection prompts for cosmetic reflection, and recognizing which failure you are looking at is most of the work of fixing it.
Evaluating whether an agent plans well
Planning quality is harder to measure than execution correctness because a plan can look reasonable and still be wrong in ways that only show up once it runs, and a plan can look unusual and still be the right call for a case the reviewer did not anticipate. A few concrete signals are still worth tracking. Plan-revision rate, how often a generated plan gets thrown out or substantially rewritten mid-execution, tells you whether your upfront planning is generating hypotheses that actually hold up, and a rate that creeps upward over time is often the first visible sign that the planning prompt or the assumptions it relies on have drifted out of sync with how the task actually behaves. Decomposition quality can be checked directly by asking, for a sample of completed tasks, whether the subtasks generated actually covered the goal and were correctly ordered, which is slow to check by hand but catches wrong-grain and false-independence problems that are otherwise invisible until they cause a failure. Time and cost spent on planning relative to execution tells you whether the deliberation is proportionate to the task, and a system spending most of its budget deciding what to do rather than doing it is a candidate for simplifying down to a less elaborate planning strategy.
The most informative single practice is to keep a running collection of tasks where the agent's plan looked fine on paper but the outcome was wrong anyway, because that gap, between plans that pass review and outcomes that fail, is exactly where your planning strategy is systematically blind. Replaying those cases against a revised planning prompt or a different technique, decomposition instead of reactive, added reflection, a different replanning trigger, and checking whether the revision closes the gap, is a slower process than watching a single demo run succeed, but it is the only way to know whether a change to how the agent plans is actually an improvement rather than a plausible-looking guess.
A reference approach
Pulling the pieces together, a planning layer that holds up in practice tends to share a recognizable shape regardless of exactly which techniques it uses. It starts by classifying the task, fixed-shape workflow or genuinely open-ended, and only invokes planning machinery for the latter, because forcing planning onto a task that did not need it is pure overhead. For open-ended tasks, it generates an initial plan when the task is long or the actions are consequential enough that coherence and reviewability are worth the upfront cost, and falls back to reactive, step-at-a-time decisions when the task is short enough that a full plan would cost more to produce than it saves. It decomposes goals that are too large for one plan to hold, stating the dependencies between subtasks explicitly rather than assuming independence, and it hands subtasks to workers with enough context to succeed and requires a summary back that is rich enough to inform the next decision. It checks, after every step, whether the plan's assumptions still hold, and replans specifically when a step contradicts something the plan depended on rather than at every minor surprise. It reserves reflection and multi-path search for the steps where being wrong is expensive and a single pass is not reliable enough, rather than applying either uniformly. And it tracks plan-revision rate, decomposition quality, and the ratio of planning cost to execution cost as ongoing signals of whether the whole layer is earning its keep.
None of these pieces is exotic on its own, and none of them needs to be present from day one. The natural path is to start with the simplest planning strategy the task can tolerate, usually reactive, one-step-at-a-time decisions, and add the heavier machinery, upfront plans, decomposition, hierarchy, reflection, search, specifically in response to the failures you actually observe rather than the ones you imagine in advance. A task that turns out to need coherence across many steps will show you that need through wandering, directionless behavior; a task that turns out to be too large for one plan will show you that need through a plan that never quite covers the goal; a task where single-pass reasoning is unreliable will show you that need through mistakes a second look would have caught. Building planning machinery in response to observed failure, rather than speculatively up front, keeps the system as simple as the task allows while still growing the sophistication that harder tasks actually demand.
A worked example: an agent that triages a production incident
Abstract descriptions of planning techniques are easier to evaluate against a concrete case, so consider an agent tasked with triaging a production incident: error rates on a checkout service have spiked, and the agent has been given read access to logs, metrics, and the deployment history, with the goal of identifying the likely cause and proposing a fix. This is squarely an open-ended task, the right sequence of investigative steps depends entirely on what each step turns up, which immediately rules out a fixed workflow and puts the agent in planning territory.
A purely reactive agent might start reasonably, check the error logs, notice a spike in timeout errors, check recent deploys, notice one shipped an hour before the spike began. That is a coherent short chain, and for an incident this contained, reactive one-step-at-a-time reasoning is plausibly enough on its own. But suppose the timeout errors turn out to be a red herring, a downstream symptom of a database connection pool exhausting under load rather than the deploy itself, and the deploy that looked suspicious is unrelated. A purely reactive agent, with no persistent plan to fall back on, risks tunneling on the first plausible lead, the recent deploy, and building an entire investigation on top of a wrong initial hypothesis, because nothing in its process asked it to hold multiple candidate explanations in view at once.
A plan-then-execute approach handles this better by generating, before diving into any one lead, an explicit set of candidate hypotheses worth checking: recent deploy, connection pool exhaustion, upstream dependency degradation, and a traffic spike beyond normal capacity, each with a cheap check that would confirm or rule it out. Executing that plan means running the cheap checks first rather than committing early to the first lead encountered, and the plan itself is a reviewable artifact, a human on call could glance at the four hypotheses and the checks proposed for each before the agent burns any time, which matters a great deal in an incident where a human is likely watching closely and wants to understand the reasoning, not just receive an answer at the end.
Replanning enters once the cheap checks come back: if the connection pool check reveals exhaustion while the deploy and traffic checks come back clean, the remaining plan should be rewritten around that finding rather than continuing to investigate the now-deprioritized deploy hypothesis out of momentum. This is exactly the assumption-contradicted trigger described earlier, the plan assumed all four hypotheses were live candidates, evidence eliminated three of them, and the plan needs to shrink to reflect that rather than plodding through the original four in order regardless of what has already been learned.
Decomposition shows up naturally once the cause is identified: "fix the connection pool exhaustion" is itself a goal, not a single action, breaking into confirming the pool size configuration, checking whether a recent traffic pattern change increased concurrent connection demand, proposing either a configuration change or a code fix for connection lifecycle management, and validating the fix against a staging environment before it touches production. Each of those is concrete enough to execute directly, and the validation step in particular is exactly the kind of consequential, hard-to-undo action where a brief reflection pass, does this fix actually address the confirmed root cause, or does it merely address the symptom noticed first, is worth the extra reasoning it costs, because shipping a fix that patches a symptom while the underlying exhaustion recurs under the next traffic spike is a worse outcome than the extra few seconds of reflection would have cost.
Notice what did not happen in this example: no tree search over dozens of reasoning branches, no elaborate multi-agent hierarchy with several layers of managers and workers. The incident was handled with an upfront hypothesis-driven plan, one replan triggered by contradicted evidence, one layer of decomposition once the cause was found, and one targeted reflection pass on the highest-stakes step. That proportionality, reaching for exactly the techniques the task's own shape called for and no further, is the actual craft this piece has been building toward, more than any single technique on its own.
The bottom line
Planning is the layer that decides what an agent should do, sitting logically upstream of the loop that decides how reliably it gets done, and conflating the two is a common source of confusion when an agent misbehaves, since a bad outcome from a good loop executing a bad plan looks, from the outside, exactly like a bad outcome from a bad loop executing a good plan, and the fix for each is entirely different. Reactive planning is fast and simple and right for short, low-stakes, easily-corrected tasks. Plan-then-execute buys coherence and reviewability at the cost of needing an explicit mechanism to notice when the plan no longer fits. Decomposition and hierarchy let a system take on goals too large to plan flatly, at the cost of getting the manager-worker interface and the subtask boundaries right. Reflection and search buy reliability on the decisions where a single pass is not good enough, at a real and worthwhile cost in compute. None of these is a universal answer, and the actual skill in building an agent that plans well is matching the technique to the task, adding exactly the deliberation the task demands and no more, so that the agent thinks as hard as the problem requires and no harder.
The throughline across all of it is that a plan is a tool for managing uncertainty about a task whose shape is not fully known in advance, not a ritual to perform for its own sake. Where the shape is known, skip the ritual and run the workflow. Where it is not, generate a plan, hold it loosely enough to revise when reality disagrees with it, break it apart when it is too large to reason about whole, and spend extra deliberation exactly where being wrong is expensive. Get that matching right, and the agent will spend its reasoning where reasoning pays for itself, which is the entire point of building a planning layer instead of just letting the model wing it one step at a time.