Why multi-step tasks need plans that persist across runs

The easiest way for a long-running AI task to fail is often not a tool error. It is losing the plan after the first round. The short answer is this: if an assistant writes a plan only for the current turn and then relies on “re-reading context” to continue later, long tasks will drift sooner or later. Reliable execution requires the plan itself to persist across runs and to be updated after every meaningful step. That is the real value of update_plan in GoWork.

For execution-oriented assistants, a plan is not decoration for the user and not a private chain-of-thought substitute. It is external task state. It records what has been done, what comes next, what has been verified, and where the path changed after a failure. If that state does not survive across turns, the assistant has to reconstruct the task from chat history every time a continuation happens. That reconstruction is where ordering mistakes, repeated work, and forgotten verification begin.

If you have already read Why AI assistants should answer task status in chat, Resume AI tasks after failure instead of restarting, and Recall before clarification: when assistants should remember before they ask, this article answers the lower-level systems question underneath them: why is it not enough to plan inside one turn, and why must multi-step plans persist across runs?

The short answer: the real problem is not whether the model can plan, but whether the plan survives

A lot of discussion around AI agents focuses on whether the model can break a task into steps. In practice, the more important question is different: will those steps still exist next turn, will their status still be accurate, and can the assistant continue along the same execution path instead of improvising again?

It helps to separate three levels:

making a plan — the assistant can break the task into steps;
following a plan — the assistant does not ignore the steps immediately;
persisting and updating a plan — the same task structure remains available across continuation, retries, and recovery.

Only the third level is enough for real long-running work.

That is because the hardest part of a multi-step task is rarely the beginning. It is the second, third, and later rounds. If the plan is only implicit in the current context window, two failure patterns appear quickly:

repeating finished work because the next round no longer knows what was already completed;
skipping required verification because a finished action is mistaken for a verified result.

So the issue is not only whether the assistant can plan now. The issue is whether that plan becomes durable state for later execution.

Why “planning only inside the current turn” sometimes works for short tasks and fails for long ones

Short tasks usually share three properties:

they have few steps;
they finish within one round;
they do not depend on many checkpoints that must be revisited later.

In those cases, a temporary in-context plan is often good enough because the task ends before drift has time to accumulate.

Long tasks are different. Content pipelines, batch edits, deployments with verification, desktop automation, and post-failure continuation all pass through several phases: inspection, execution, validation, correction, publishing, and reporting. Once the task reaches a second round, a non-persistent plan starts losing structure:

the assistant remembers the goal but forgets the path;
it remembers some outputs but not which ones were verified;
it remembers that something went wrong, but not exactly where or why the route changed.

This is why many assistants look competent in the first round but start “re-reading the problem” in the second. The issue is not zero capability. The issue is missing persistent task structure.

What update_plan preserves is more than a list of steps

It is tempting to think of update_plan as a task checklist, but that undersells its role.

For an execution system, a durable plan carries at least four different kinds of state.

1. execution order

It tells the system what must happen first, what depends on what, and what must be verified before the next phase can start. In a content pipeline, for example, writing and QA must happen before deployment, deployment before search submission, submission before distribution, and distribution before logging and commit. Without a persistent order scaffold, later rounds start rearranging the workflow.

2. step status

States such as pending, in_progress, done, verified, and skipped are not cosmetic labels. They define what the assistant may rely on next. The distinction between done and verified is especially important: an action being completed does not mean its result has been checked.

If the assistant forgets that difference across turns, it may treat an unchecked output as a stable prerequisite and compound the risk later.

3. plan revisions and why they happened

Real tasks do not follow the original plan perfectly. Builds fail, platform rate limits appear, paths are wrong, tools behave differently, and assumptions collapse. If the assistant changes course silently but never writes that revision back into the plan, later rounds lose the reason for the new path. They see path B, but they no longer understand why path A was abandoned.

4. handoff meaning for the next run

A persistent plan is also a compact handoff to the assistant’s future self. Instead of forcing the next round to reconstruct the whole task from scattered history, it gives continuation a maintained structure to resume from directly.

Why does cross-run plan visibility improve continuation quality so much?

Because it turns “continue this task” from a vague intention into state restoration.

When a task resumes after interruption, the assistant needs immediate answers to three questions:

which steps are already finished?
which steps are finished but still unverified?
what should happen next, instead of what should be repeated?

Without a persistent plan, the system has to infer all of that again from chat, tool outputs, files, and partial memory. That is slow, and it is especially bad at recovering verification state and the reasons behind earlier plan changes.

With a maintained plan, the next round can immediately see:

which steps are already verified;
which one is still in_progress;
where the workflow diverged after a failure;
what the natural next action is.

That shifts continuation from “reanalyze the whole history” to “resume from current task state.”

Why does task status become unreliable without a persistent plan?

Because when the user asks “where is it now?”, the assistant must answer from the structure of the task, not from the most recent fragment of activity.

As discussed in Why AI assistants should answer task status in chat, a real status answer needs a current phase, recent observation, and next step. The “current phase” part depends heavily on plan structure.

Without a persistent plan, assistants often distort status in three ways:

they mistake the last attempted action for the current phase;
they treat a failed attempt as a completed step;
they say “still working on it” but cannot explain the actual next step.

So the reliability of status reporting depends more than it seems on whether the task plan has been kept alive.

Why is this especially important for failure recovery?

Because the hardest question after failure is not “did something fail?” It is where exactly should execution resume?

For example:

after a failed build, should the assistant fix content or configuration?
after interrupted publishing, should it retry the same platform or move on and report the partial result?
after a tool error, was the problem in parameters, path assumptions, or unmet preconditions?

Without persistent plan state, many systems collapse all of this into “start over.” But restarting is often the worst option because it:

wastes time by repeating safe work;
risks extra side effects;
throws away the exact location and meaning of the failure.

A persistent plan lets the assistant distinguish clearly between:

what is complete and should not be repeated;
what is half-done and should be resumed;
what failed verification and requires a plan revision;
what is blocked on an external dependency and must wait.

That is why a system that can truly continue after failure does not merely remember that failure happened. It remembers which cell of the plan failed and what the revised path is now.

Why is chat text alone not enough to serve as the plan?

Because chat is narrative, not maintained state.

A thread may well contain sentences like “next I will do A, then B.” But plain conversational text has three weaknesses:

it decays quickly as more messages appear;
it does not expose current status directly because someone has to reread and interpret it;
it accumulates stale versions when the plan changes.

A mechanism like update_plan matters because it upgrades the plan from scattered prose into structured, current task state. The assistant does not have to ask “what did I once say I might do?” It can ask “what is the latest plan right now?”

A practical rule: which tasks really need cross-run plan persistence?

A simple heuristic works well: if a task has more than three steps, requires intermediate verification, and is likely to continue across turns, it should not rely on temporary turn memory alone.

Typical examples include:

content pipelines with writing, QA, deployment, submission, distribution, and logging;
desktop automation with app launch, UI discovery, action, and result verification;
batch code changes with search, edits, tests, repair, and retest;
scheduled workflows that must execute, observe, decide, and report;
post-failure continuation where the system must resume from a known checkpoint.

All of these share the same property: the assistant must know not only what the goal is, but where it currently stands inside the path.

What difference does persistent planning make for users in practice?

Not just prettier plans. It changes collaboration in three important ways.

1. tasks drift less

Users delegate a goal, not an invitation for the assistant to reinterpret the whole approach every round. Persistent planning keeps later execution aligned with the same backbone.

2. progress becomes explainable

When the user asks for status, the assistant can answer in plan terms: which step is verified, which one is in progress, and which one changed because of what. That is much more actionable than generic reassurance.

3. continuation and handoff become cheaper

Whether the same assistant continues in the next round or another run picks up the task later, a preserved plan dramatically lowers the cost of resuming because the task structure is already explicit.

FAQ

FAQ 1: If the model is already strong, why persist the plan at all?

Because intelligence is not the same as continuity. A model can plan well in the current turn and still drift badly across turns if the task structure is not preserved.

FAQ 2: Does every task need update_plan?

No. One-step tasks usually do not. But once a task becomes multi-step, contains verification, or may continue later, explicit plan maintenance is far more reliable than relying on temporary context alone.

FAQ 3: Why must done and verified stay separate?

Because “done” only means the action happened. “Verified” means the result was actually checked. Many long-task failures come from treating unchecked output as if it were already trustworthy.

FAQ 4: Why can’t the chat transcript itself be the plan?

Because transcripts are good for telling the story of what happened, not for expressing the current authoritative task state. Plans need to be structured, revisable, and immediately usable for the next step.

If you have already noticed that the hard part of long-running AI work is not the first round, but whether the assistant can continue cleanly in later rounds, then the real issue is no longer “planning quality” alone. It is whether task structure survives across runs. That is why GoWork treats update_plan as a discipline for long tasks: not so the assistant can list steps once, but so it can keep walking the same task map later. To try that model in practice, start with the GoWork download page, scheduled workflows in GoWork, and how continuation works after failure.