Give a language model the instruction “renew the staging SSL certificate” and it will produce a confident, plausible paragraph. Give the same instruction to a system that actually has to do it, and you learn within about ten minutes that the task is really eleven small tasks: check the current expiry date, confirm the domain record, request the certificate, satisfy the ownership challenge, install it, reload the web server, verify HTTPS responds, update the asset inventory, notify the on-call channel. Nobody wrote those steps down anywhere. Something has to generate them, track which ones are done, and decide what happens when step six fails because the DNS record is stale.
That work is planning, and it’s the part of agent design that gets the least attention and causes the most failures.
Planning is bookkeeping, not poetry
It’s tempting to treat planning as a prompting trick. Ask the model to think step by step and hope the reasoning holds. In practice, planning in a working agent is closer to project management than to creative writing. Four jobs have to get done, and skipping any one of them shows up later as a mysterious failure at step nine.
- Decomposition. Turning one goal into a set of subtasks small enough that each can be checked. “Migrate the database” is not a subtask. “Run a schema diff against production and save the output” is.
- Sequencing. Knowing which steps depend on which. You cannot verify HTTPS before the certificate is installed, and you should not install before the ownership challenge passes.
- State tracking. Remembering what’s finished, what’s in flight, and what the intermediate results were. This is where most agents leak information, because the plan lives in a context window that keeps getting rewritten.
- Replanning. Recognising that an assumption broke and generating a new path rather than retrying the same broken step for the fourth time.
Which of these sits in the model and which sits in your code is an architectural decision, and it’s one of the choices that most influences whether the whole system holds together. There’s a useful breakdown of where the planner belongs alongside memory, tooling and the execution loop in this look at AI agent architecture and the parts that actually decide whether it works.
The arithmetic that kills long plans
Here’s the number that changes how people design these systems. Suppose each step your agent takes is 95% reliable. That sounds excellent. Run ten steps and the chance that all of them land is about 60%. Run twenty and you’re at 36%. The agent isn’t getting dumber as it goes; the errors simply have more chances to happen.
Real systems do better than this because many failures are recoverable. A malformed API call returns a 400, the agent retries with corrected parameters, life continues. But the failures that matter are the ones that don’t announce themselves: a search that returns a plausible-looking wrong document, a date parsed as March 4th instead of April 3rd, a tool call that succeeds against the wrong environment. Those propagate silently and poison everything downstream.
This is the core reason long-horizon plans feel impressive in a demo and fragile in production. The demo runs eight clean steps with a human watching. Production runs forty steps overnight with nobody in the room. If you want the gory detail on where these systems come apart, where AI agents actually break down is worth twenty minutes of your time before you ship anything with more than a handful of steps.
Four planning patterns that survive contact with reality
Plan-and-execute with checkpoints
The agent drafts a full plan up front, then executes it step by step, pausing at defined checkpoints to verify the world still matches its assumptions. Checkpoints after irreversible actions are non-negotiable: before sending an email, before deleting a record, before merging a branch. The plan is a document the system can re-read, which makes it debuggable in a way that a single rolling thought stream never is.
Hierarchical planning
One planner breaks the goal into five or six phases. Each phase gets handed to a worker agent that does its own decomposition inside a narrower scope and reports back a summary. The advantage isn’t intelligence, it’s containment: a worker that goes off the rails has a much smaller blast radius, and the planner’s context stays clean enough to reason about. It also costs more, so reserve it for genuinely large jobs.
Interleaved reasoning and acting
The agent reasons one step, takes one action, looks at the result, reasons again. Slower and cheaper per decision than full up-front planning, and much better at tasks where the environment is the source of truth — browsing, debugging, exploring an unfamiliar API. The trade-off is that it drifts. Without an explicit plan to check against, agents in this mode tend to wander into interesting side quests.
Fixed playbooks with a planning layer on top
For repetitive work, don’t let the model invent the plan every time. Encode the known-good sequence as a template, and let the model handle the parts that genuinely vary: which account, which values, what to do when a step returns an unexpected state. Reliability goes up sharply, and so does the ability to explain to a customer why something happened. The use cases that benefit most from this treatment overlap heavily with the ones that AI agent use cases that actually ship tend to share.
The planning budget nobody accounts for
Planning costs tokens and time. A ten-step plan generated before the first action can add two to four seconds of latency and a few thousand tokens before the user sees anything. For a chat assistant answering “what’s our refund policy,” that’s pure waste. For a task that touches fifteen systems and takes twenty minutes, it’s the cheapest insurance you’ll buy all year.
A rough rule that holds up: plan explicitly when the task has more than about eight steps, when it touches three or more tools, or when any step is irreversible. Otherwise let the agent act with a light reasoning loop and skip the ceremony. Being selective about this matters more than picking the cleverest planning algorithm, because half the agents that feel sluggish are just planning things that didn’t need a plan.
Test the plan, not just the answer
Most evaluations score the final output. That tells you whether the agent got lucky. To debug a planner you need to see the plan it generated, the order it chose, and the moment it decided to deviate. Log plans as structured objects, not as prose buried in a transcript, and you’ll find that a large share of failures are planning failures that look like execution failures from the outside.
Two tests earn their keep. First, a plan-quality check: give the agent the same goal five times and see whether the plans are consistent in structure. Wildly different decompositions on identical inputs usually mean the goal is underspecified, not that the model is creative. Second, a disruption test: kill a tool mid-run, return a stale value, or have a step come back with an unexpected shape, and watch whether the agent replans or grinds. A walkthrough of how this plays out across a real execution trace is in inside an AI agent workflow.
Put the plan where a human can see it
The most underrated design move is making the plan visible and editable. Show the user the five steps before the agent starts, especially for anything that sends, spends, or deletes. Let them delete step three. Let them reorder. You get three benefits at once: a natural approval gate, a correction signal you can feed back into your prompts, and a much shorter conversation when something goes wrong, because the user can point at the step that was wrong instead of describing the bad outcome in vague terms.
This is also where planning intersects with safety in a practical way. An agent that can articulate what it is about to do, and why, is an agent whose mistakes are catchable before they cost money. The failure modes that hurt most are rarely dramatic; they’re the quiet ones where nobody noticed the plan had drifted three steps ago. There’s a good catalogue of those in AI agent risks: what actually goes wrong when software starts acting, and almost every entry traces back to a plan that nobody inspected.
Start with a plan format you can print on one screen, checkpoints at the irreversible steps, and a log that records every revision. Those three things will do more for reliability than a smarter model will, and they’re the difference between an agent you can operate and one you can only demo.