Agent planner

What is an agent planner?

This is the part that decides every step before anything starts. Thinking ahead is not what makes it special, because every AI agent does that quietly. What makes it special is what it leaves behind. It produces a written plan that stays available as its own item. It is apart from whatever happens during the run of work.

That artefact is the entire distinction, and it is worth being precise about what it separates.

Both are legitimate and they suit different work. The trade is adaptability against reviewability, and the reason to be deliberate about it is that one of those two is a governance property and teams tend to choose on engineering grounds alone.

What does a plan contain?

It needs to hold much more than a list of steps if it is going to be worth reviewing. A bare list of steps shows what the agent intends to do, but it does not show whether the plan is sound. The person who approves it is then going through the motions instead of exercising real control, and everyone involved can usually tell.

Five elements, and the last two are what make review meaningful.

• The steps, in order, with dependencies. Which must follow which, and which can run alongside each other. Parallelism is a plan property rather than an execution detail.
• The tool or system each step will touch. A reviewer scanning for the step that writes to a production system needs it visible without reading prose.
• The expected outcome of each step. What the planner believes will come back, which is what makes a deviation detectable at the step rather than at the end.
• The assumptions. What the planner took as true in order to produce this sequence. Usually absent, and usually where the plan is wrong.
• The stopping condition. What counts as finished, and what counts as failed. A plan without this describes a journey with no arrival.

The fourth is worth insisting on even though it is the least common. A plan states what the agent intends; the assumptions state what would have to be true for the plan to work, and a reviewer can evaluate the second far faster than the first. Most plans that fail were internally coherent and rested on something nobody checked.

Why is the plan the only governable artefact?

Timing is the whole answer. Inputs show up before any decision has been reached, and outputs show up once the consequences are already real. The plan occupies the gap between those two: the decision has been made, nothing has yet been done about it, and stopping remains free of charge.

Three things follow from that timing, and they are the practical case for planning in any regulated process.

• Approval before the fact is a different control from review after it. One prevents, the other documents. Only a plan supports the first, which is why this comes up in every discussion of human oversight obligations.
• Deviation becomes detectable. With a stated plan, a step that was not in it is an exception a system can raise automatically. Without one, every action is equally unexpected and nothing can be flagged.
• The plan is cheap to reject. Stopping a plan costs nothing. Stopping an execution means dealing with partial work, which is the problem described at kill switch.

When does a plan get revised?

That decision is the real design work, and it is routinely left implicit. A plan is a hypothesis about a world the planner has not yet touched, so something will differ, and what happens next determines whether you have planning or theatre.

Three policies, with what each costs.

1. 01
   Never reviseExecute the plan as approved and fail if it does not fit. Cost: brittle, and it fails on trivial surprises. Where it is right: processes where an unexpected condition genuinely should stop and escalate.
2. 02
   Revise at every stepReconsider the remaining plan after each result. Cost: the approved plan stops meaning anything, since what runs may share nothing with what was reviewed. This is step-by-step deciding with extra ceremony.
3. 03
   Revise on failure, within boundsReplan only when a step does not return what was expected, and only inside the approved envelope. Cost: more design work up front. Why it is the practical answer: the approval still means something.

The second deserves naming because it is common and rarely recognised. A system that replans after every step has the costs of planning and none of the benefit: you pay for plan generation repeatedly, and the artefact somebody approved bears no reliable relationship to what eventually ran. If that is your replanning policy, the honest move is to drop the plan and treat the system as what it is, which is covered at agentic workflow.

How do planners fail?

They turn out plans that hold together perfectly and cannot be carried out. Reasoning happens over a world the planner has not looked at, so a flawless internal structure can still point at an unavailable system, a permission that was never granted, or a record nobody created.

Four failure shapes, and the first is the characteristic one.

• Valid but infeasible. Every step follows logically and step four requires access nobody granted. Nothing in the plan looks wrong, because nothing in it is wrong except its relationship to reality.
• Over-decomposition. A three-step task planned as fourteen, because more detail reads as more thorough. Each additional step is another chance to fail and another thing to pay for.
• The plan that assumes its own success. No alternative branch anywhere, so the first unexpected result has nowhere to go and the agent improvises outside anything that was reviewed.
• Planning when planning was not needed. A single lookup wrapped in a four-step plan, which adds latency and cost to something that required neither.

The first is worth testing for deliberately, because it has a cheap diagnostic. Have the planner state, for each step, what must be true for that step to be possible, then check those conditions before execution rather than discovering them during it. Most infeasible plans announce themselves in that list.

When do you need an agent planner?

You need one in three situations. The first is when a person has to approve the work before it starts. The second is when the order of the steps matters for a reason outside the task itself. The third is when a failure halfway through would be expensive. In every other case, planning only adds cost and delay to work that would have gone fine without it.

Four tests, answerable before any architecture is chosen.

1. Does anybody need to approve this before it happens?

   If yes, you need a plan, because there is nothing else to approve. This single question decides it for most regulated processes.

2. Is the order itself compliance-relevant?

   Some sequences are mandated: check before act, verify before release. Where ordering carries obligation, it has to be stated somewhere that can be audited rather than emerging from a model's choices.

3. What does partial completion cost?

   If stopping halfway leaves a mess, knowing the full sequence in advance lets you decide not to start. Step-by-step agents discover the mess at step six.

4. Would you be comfortable explaining each step afterwards?

   If the answer is only yes when you know the steps in advance, that is a plan requirement expressed as a feeling. Trust it.

One closing observation about how this decision actually gets made. Planning is usually adopted for reliability and kept for governance, because teams reach for it hoping the agent will behave better, find the improvement smaller than expected, and then discover the plan has become the thing audit, compliance and incident review all depend on. That is a sound reason to keep it, and a better reason to adopt it deliberately than to arrive at it by accident.