Planning, and Why Plans Go Stale

In one line: a plan made before the first observation is a guess about a world you have not looked at yet.

Two shapes

Plan upfront. Decompose the goal into a full sequence, then execute it. The plan is coherent, the cost is predictable, and progress is legible — you can show the user step three of seven.

Plan incrementally. Decide the next step from the current state, repeatedly. Adapts to whatever comes back, and it has no notion of the overall shape, so it wanders and there is nothing to show the user.

Neither is right alone, which is why production agents do both: a coarse plan upfront for structure, refined step by step as observations arrive.

Plans go stale

The failure that matters, and it is well documented in the agent literature: the agent continues executing against an outdated world state after the environment has changed, re-invoking the same tools with similar arguments rather than re-checking what is now true.

For a personal assistant the world changes constantly and often because of the agent:

• The meeting it was going to move has been cancelled by someone else
• The email it planned to reply to has already been answered
• A step it took three actions ago changed a state that a later step assumed

That last one is specific to agents and easy to miss. The agent invalidates its own plan by acting on it. A plan that says "check availability, then book" is stale the moment the check returns something different from what the plan assumed.

Making a plan revisable

Three properties that turn a plan from a script into something the loop can work with.

Every step states its precondition. Not just "send the confirmation email" but "send it if the booking succeeded". The precondition is checkable, so a step whose assumption no longer holds can be skipped or re-planned instead of executing into a changed world.

Replan on surprise, not on schedule. Re-planning after every step wastes a model call on the common case where nothing surprising happened. Re-plan when an observation contradicts what the plan expected — which requires the plan to have expected something, which is what preconditions give you.

Keep the goal separate from the plan. The plan is disposable; the goal is not. When re-planning, start from the goal and the current state rather than patching the old plan, or errors accumulate across revisions.

Decomposition, and its failure

How finely to break down the goal is a real decision with a failure at each end.

Too coarse and a step is really several, so a failure inside it is opaque — "book the trip" failed, and nothing says whether the flight, the hotel or the calendar entry was the problem.

Too fine and the agent spends its budget on bookkeeping. Twelve steps to send an email is twelve model calls, most deciding trivia.

The useful rule: a step should be one tool call, or one decision that determines the next tool call. Anything larger should be decomposed; anything smaller should be code rather than a model call.

That last clause matters. If a step is "extract the date from this string", that is a function, not a step. Putting deterministic work inside the loop is the most common way agents become slow and expensive — the model is being asked to do things a parser does better, faster and reliably.

What the plan is for, besides execution

Two uses that justify planning upfront even when execution is incremental.

Showing the user. A plan is the only way to answer "what are you doing?" while the agent is working. Without it, a long-running task is an opaque delay, and opaque delays get cancelled.

Getting approval before acting. For anything at the draft rung, showing the plan and asking once is far better than asking per step. The user approves "book this flight, this hotel, and put it in my calendar" in one interaction rather than three — which is the difference between an assistant and an interrogation.

That second point is the strongest practical argument for upfront planning in a personal assistant, and it is a product argument rather than a technical one.

When to skip planning

The judgement to show.

For a single-step task — "what's on my calendar tomorrow" — planning is pure overhead. A model call to decide that the next step is "read the calendar" costs as much as reading the calendar.

So route: classify whether the request is single-step, and if it is, execute directly. The planner is for tasks that genuinely have a sequence, and a large share of assistant traffic does not.

That routing decision is the same shape as the retrieval routing in the conversational assistant — a cheap classifier deciding whether to spend the expensive path — and recognising it as the same pattern is worth saying.

Next: the step itself, and why a tool result is untrusted input.