We now have three of the four pillars in place. The agent has a loop (article 3), tools it can call (article 4), and memory to keep track of what it knows (article 5). All that machinery is impressive, but it’s still missing something. Without the fourth pillar, the agent would tackle every task with the same slightly-panicked “what tool should I call next?” impulse. It would work on simple tasks and fall apart on complex ones.
The missing pillar is planning. It’s what lets an agent look at a genuinely hard goal, break it down into a sequence of smaller pieces, work through them thoughtfully, and adapt when things don’t go as expected. In this article we’ll unpack what planning actually means in the context of an agent, when it matters, and how the good techniques work.
What “planning” really means for an agent
Let’s be clear about what we mean, because “planning” is one of those words that gets stretched to mean everything and therefore nothing. In an agent, planning is the reasoning step (or steps) where the agent thinks about the whole task rather than just the next action. It’s the difference between “the next thing I’ll do is call the weather tool” and “here’s my three-step plan to solve this problem, and I’ll start with step one.”
The reasoning is still just the model thinking out loud (chain-of-thought from the Prompt Engineering track), and the actions are still just tool calls. What planning changes is the scope of the thinking. It stretches the model’s reasoning across the whole task instead of just the next iteration. That’s the whole idea. Figure 1 makes the shift concrete.
Figure 1: Without planning, an agent decides the next action turn by turn. With planning, it first produces a plan of the whole task, then executes step by step against the plan, adapting when reality diverges from the plan.
You don’t need this for every task. For a simple two-tool task like the weather-and-reminder example from article 3, planning would be overkill. But for a task like “research this market and produce a briefing,” or “diagnose why our customer’s account is behaving oddly,” or anything with more than a handful of steps whose order isn’t obvious, planning is what keeps the agent coherent instead of lurching from step to step.
Two flavours of planning: upfront and iterative
There are broadly two ways to introduce planning into an agent, and it’s worth understanding both because they suit different situations.
Upfront planning. The agent starts by producing a full plan of the task, all the steps it thinks it’ll need, before taking any action. Then it works through them. This is what you’d do for a well-defined, moderately complex task where the shape is knowable at the start. “I need to: 1. gather data from source A, 2. gather data from source B, 3. compare them, 4. write the summary.” Once the plan is set, execution is largely mechanical.
Iterative planning (also called plan-and-solve or reflective planning). The agent produces a rough plan, executes the first few steps, and then revises the plan based on what it learned. It plans, acts, reflects, replans, acts. Rinse and repeat. This is what suits genuinely uncertain tasks, where you can’t tell in advance exactly what steps you’ll need because early findings shape later ones.
The choice between them mirrors real life. For a well-defined project like “make a website using this template,” you can plan the whole thing up front. For a genuinely exploratory project like “figure out why the numbers don’t match,” you have to work iteratively, because the discoveries themselves change the plan.
In practice, most sophisticated agents lean toward the iterative side, because most agent-worthy tasks are the exploratory kind (the whole reason we’re using an agent instead of a workflow, remember). Upfront planning is useful when it works; iterative planning is what handles the harder cases.
Task decomposition: the everyday planning skill
If planning sounds abstract, here’s the concrete skill it rests on: decomposition. Breaking a big goal into smaller sub-goals, each of which is more tractable than the whole thing. Every good planner, human or agent, is a good decomposer.
Consider the goal: “Prepare a market analysis for our new pricing decision.” A good decomposition might be:
- Identify the top three competitors.
- Look up each competitor’s current pricing.
- Look up recent public discussion of their pricing (blog posts, product changes).
- Note our own pricing.
- Compare across the four along key axes (price, tier structure, discounts).
- Highlight the two or three most useful strategic observations.
- Produce a concise briefing.
Now each sub-goal is small enough that it becomes obvious what tool to use for each step. Steps 1 and 2 are web searches; step 3 is another search; step 4 is a lookup in our own systems; step 5 is a compare-and-summarise, likely with the model doing the reasoning; step 6 is more reasoning; step 7 is generation. What was one intimidating goal is now a small pipeline the agent can actually run through with confidence.
Notice something important: the decomposition itself is reasoning work the model does, driven by a good prompt at the planning step. You don’t hand-code the steps; you prompt the model to produce them. Which is why writing a good planning prompt is one of the most under-appreciated skills in agent building.
Reflection: the underrated superpower
The single most useful planning-related technique I know is called reflection, and it’s genuinely simple. After each significant step (or every few steps), the agent takes a beat, looks at what’s happened, and asks itself: is this going the way I expected? Am I still on the right path? Do I need to change my plan? Then it either continues, adjusts, or backtracks.
You can implement this with the same tool-loop machinery you already have, just by adding a “reflection” step at chosen points. In a ReAct-style trace:
Thought: I've now gathered pricing for two of the three competitors, but the third one doesn't have public pricing.
Reflection: My original plan assumed all three would have public data. I should either try harder for competitor 3 (industry reports, comparison sites), or note the gap and proceed with the two we have.
Decision: I'll do one more targeted search, and if that fails, note the gap and continue with the analysis.
Action: web_search("Competitor C enterprise pricing 2026")
Observation: ...That short “Reflection” beat is genuinely powerful. It catches wrong turns early, before the agent goes several steps down a bad path. It’s cheap (just another model call, which was going to happen anyway) and pays for itself many times over on complex tasks.
The rule of thumb: build reflection points into any agent doing tasks longer than about five steps. Not after every single action (that’s overkill and expensive), but at natural checkpoints. It’s the single easiest way to make a complex agent noticeably more reliable.
When planning fails, and how to recover
Real tasks don’t always go according to plan. A tool returns an error. A search returns nothing useful. An expected assumption turns out to be wrong. Good planning handles these gracefully by adapting.
The default failure of naive agents is to keep hammering at the same broken plan, or to spiral into confusion. Better agents notice when things aren’t working and change course. This is where reflection earns its keep, but it’s also where good prompting and good tool design matter. Some habits that help:
Prompt the agent to notice when it’s stuck. In your system prompt or planning prompt, explicitly instruct: “If you find yourself trying the same thing repeatedly, or your plan isn’t producing progress, step back and consider whether the plan needs to change.” Sounds simple; makes a big difference.
Return errors gracefully from tools. As we saw in article 4, tools that return {"ok": False, "error": ..., "hint": ...} let the agent reason about what went wrong. Tools that just crash or return empty results give the agent nothing to work with.
Build in an escape hatch. For any complex task, the agent should be able to gracefully stop and say “I can’t complete this fully, here’s what I have and here’s what got stuck.” A stuck agent that gives you 70% of the answer is more useful than one that spins for an hour and produces nothing.
Figure 2 shows the full planning pattern in action, including the reflection loop.
Figure 2: A robust agent planning pattern. Produce a plan. Execute one or a few steps. Reflect: is this working, or do I need to adjust? Continue, revise, or gracefully stop. This cycle is what turns a fragile “plan once and hope” approach into a robust “plan, act, learn, adapt” one.
A gentle warning about overplanning
One caution to save you a lot of pain. There’s a subtle failure mode where an agent produces beautiful, detailed multi-step plans and then… never quite gets around to executing them well. Every step of the plan itself triggers more sub-planning, and the agent spends more time planning than doing. This is sometimes called planning paralysis, and it’s genuinely a thing.
The fix is to lean on simplicity in your prompts. Ask for a rough plan, not an exhaustive one. Say something like “produce a brief three-to-five-step plan, then start executing.” And in your reflection prompts, prefer questions like “am I making progress?” over “should I revise my plan?” (which invites yet another plan-revision cycle).
The best agents plan just enough, then act, then reflect just enough, then act more. Not endless planning. Not blind action. A balance.
The four pillars, in place
Look back at what we’ve built. In article 3 we saw the loop, in article 4 we gave the agent tools to act with, in article 5 we gave it memory to work across time, and now we’ve given it the reasoning to plan and adapt. Loop, tools, memory, planning: those are the four pillars, and every serious agent design draws on them.
The next article moves from the individual pillars to how experienced practitioners combine them into recognisable, reusable shapes. There are a handful of design patterns for agents that come up over and over, in production systems from every serious team. Knowing them well means you don’t reinvent them from scratch each time. That’s article 7, and it wraps up the foundations before we get our hands dirty building an agent in article 8.
Next in the series: Agent Design Patterns, the reusable shapes for reliable, well-behaved agents.