Replanning Is a Bounded Control Loop, Not Improvisation

The moment a plan begins to run, it meets a world it did not fully model. A tool returns something the plan never anticipated, a resource that existed at design time has moved, a value comes back valid but wrong for what the next step assumed. This is not a defect in the planning. It is the ordinary condition of acting in an environment you do not control, and no amount of care up front removes it. The real question a system designer faces is not whether the plan will diverge from reality but what happens at the moment it does: whether the agent can revise its course without losing the thing it set out to accomplish.

That capacity to revise mid-execution is what separates a system that survives contact with reality from one that either shatters on the first surprise or wanders away from its goal while adapting. It is also the single feature most likely to be implemented as an afterthought, tacked on as “let the model figure it out when something breaks.” Treated that way, it becomes the most dangerous part of the system. Adaptive planning earns its keep only when replanning is a bounded, goal-checked control loop, deliberate about when it fires, hard-capped in how long it runs, and defended against the quiet erosion of the original objective. Left unbounded, the same mechanism that makes an agent robust is what lets it loop forever or solve the wrong problem convincingly.

The whole distinction is when the steps get decided

Two planning postures sit at opposite ends of a spectrum, and the clarifying question that separates them is simple: at what point are the steps chosen? In static planning, every action is fixed before execution begins. The sequence is authored in advance, and running it introduces no new decisions. Whatever the agent does, it was going to do that, in that order, and you knew it beforehand. In dynamic planning, the model chooses or revises its next step during execution, reacting to what it has actually observed rather than to what was predicted. The steps are decided at inference time, not design time.

Everything that follows about adaptability and risk descends from that one difference. A static plan is predictable because it is settled; you can read it, test each step in isolation, audit the whole path before a single action fires, and when something fails you can localize the failure precisely because the structure never changed underneath you. A dynamic plan gives up that settledness in exchange for reach. It can pursue goals that cannot be fully specified in advance, where the right second step genuinely depends on what the first one returns. But because its later steps were never pre-audited, the sequence that actually executes is one no one inspected before it happened.

In practice the two are not a binary choice, and the strongest systems are not purely one or the other. They fix structure wherever the task allows it and reserve dynamic decision-making for the specific junctures where the work genuinely cannot be scripted. Static scaffolding carries the parts of the task whose shape is known; dynamic planning handles the parts where the environment gets a vote. Treating the choice as all-or-nothing is itself a design error, because it either forfeits adaptability the task needed or spends unpredictability the task never required.

Adaptability is a cost you accept, not a capability you get for free

There is a temptation to describe dynamic planning purely as an upgrade, as if adding the ability to replan strictly improves the system. It does not. It trades one property for another. What you gain is the capacity to handle open-ended goals and unforeseen conditions. What you spend is predictability, and predictability is not a luxury. It is what made the system auditable, testable, and cheap to reason about.

The honest framing is that dynamic planning increases unpredictability by construction, and that increase is a liability you take on knowingly. The correct engineering response is not to hope the model stays on track. It is to compensate for the unpredictability you introduced with machinery that observes and constrains it: monitoring that watches what the agent is actually doing, logging that makes each decision reconstructable after the fact, and explicit fallback paths for when the adaptive behavior goes somewhere it should not. A dynamic planner without that surrounding apparatus is not adaptive. It is merely unaudited. The adaptability is real, but it is only safe to the degree that you have built the means to see it and to stop it.

This is why “let the model replan when needed” is not a design. It names the capability without paying for it. The cost of dynamic planning is the observation and control infrastructure that has to sit around it, and a system that wants the adaptability without building that infrastructure has not made the trade. It has simply hidden the bill.

Four kinds of event invalidate a running plan

If replanning is going to be deliberate rather than reflexive, an agent needs a clear account of what actually counts as a reason to reconsider. Left vague, either everything looks like a trigger and the agent thrashes, or nothing does and it plows ahead on a plan the world has already invalidated. There turn out to be four distinct categories of event that legitimately force a plan back open, and they are worth separating because each is a different kind of problem and calls for a different assessment.

The first is a failed action: a tool call that returns an error, times out, or comes back empty when the plan assumed a result. This is the most visible trigger, because the failure announces itself. The second is subtler and more dangerous: an unexpected result, where the action succeeded and returned something technically valid, but that value contradicts what the next step was built to consume. Nothing errored. The plan is simply now standing on an assumption that just proved false. The third is a changed environment, where the world itself has shifted since the agent started, so that steps which were valid when the plan was authored no longer apply to the state that now exists. The fourth is a constraint violation, where the next action the plan would take would cross a goal boundary or a safety limit the agent is required to respect.

Recognizing which of the four you are in is the first act of handling the situation, because the response differs. A failed action may be transient and worth a retry before anything else. An unexpected result means an assumption is wrong and the reasoning built on it has to be re-examined, not merely re-run. A changed environment invalidates steps regardless of how well they were designed, because their preconditions no longer hold. A constraint violation is the one case where continuing is not an option under any circumstances, because the whole point of the constraint is that it is not negotiable. Collapsing these into a single “something went wrong, replan” reaction throws away exactly the diagnosis that tells you what the right response is.

Not every deviation deserves a new plan

Having a reason to reconsider is not the same as having a reason to discard the plan, and conflating the two is a common and expensive mistake. Deciding to hold the plan or throw it out is among the least mechanical choices in the whole design, and it goes wrong in both directions. An agent that replans at every minor deviation is as broken as one that never replans at all; it just fails more expensively.

What settles it is a single test: can the plan in hand, patched, still land the goal it was built for? If a core assumption the plan was built on has been invalidated, then the plan is resting on something that is no longer there, and continuing to execute it is executing a fiction. That warrants replanning. But if the deviation is minor and the original path remains recoverable, replanning is not just unnecessary, it is harmful. Each cycle has a price in tokens and in wall-clock time, and a subtler one on top of that: every regeneration is another chance for the agent to veer toward something that answers most, but not all, of what was actually asked. A plan that is 90 percent of the way to the goal and has hit a small, recoverable snag is often far better continued and patched than torn up, because tearing it up reintroduces all the uncertainty that the completed work had already resolved.

The disposition to cultivate here is a bias toward the smallest intervention that restores validity. Retry before you revise a step. Revise a step before you revise the plan. Revise the plan before you escalate out of it. Each level up costs more and risks more, and the reason to climb is that the level below genuinely cannot recover the goal, not that climbing feels like doing something. Unnecessary replanning is not caution. It is a way of converting a small, localized problem into a large, systemic one.

An unbounded replanning loop will run forever

Once replanning is warranted, it needs limits, because the mechanism that lets an agent revise its plan is also a mechanism that lets it revise, fail, revise again, fail again, without end. An agent that runs into the same wall repeatedly will keep manufacturing new plans to route around it, and if nothing stops that cycle, it does not converge. It burns resources indefinitely while making no progress, and from the outside it looks busy the entire time.

Two mechanisms bound the loop, and they guard against different failures. The first is a hard cap on how many replanning cycles are permitted before the agent must escalate or stop. This is not a tuning parameter to be set generously. It is the backstop that guarantees termination, and its job is precisely to fire in the case where the agent would otherwise loop forever on an obstacle it cannot get past. When the cap is reached, the correct behavior is to hand the situation to something outside the loop, whether that is a human, a fallback path, or a clean failure, rather than to try once more. The cap exists to convert an infinite failure into a bounded, visible one.

The second mechanism is a check that runs before each revised plan is allowed to execute: does this new plan still satisfy the original task requirements? This is a different guard from the iteration cap. The cap protects against running forever; the goal check protects against succeeding at the wrong thing. Without it, an agent can generate a revised plan that neatly overcomes the obstacle in front of it and resume execution, having quietly abandoned part of what it was supposed to deliver. The two together are what make the loop adaptive without making it unbounded: one ensures it ends, the other ensures that what it does before it ends still serves the goal.

Goal drift is the failure that hides

The most dangerous failure mode in an adaptive system is not the loop that runs forever, because that one is at least visible. It is goal drift, and its danger is precisely that it does not announce itself. Drift happens when the agent, cycle by cycle, revises its plan to overcome each obstacle it meets, and the accumulated revisions carry it to a plan that no longer satisfies the requirements it started with. Each individual revision looked reasonable. Each one solved a real, immediate problem. And the sum of them solves a different problem than the one that was posed.

What makes drift so hard to catch is that it is locally rational at every step. There is no single moment where the agent decides to abandon the goal. It never decides that at all. It makes a sequence of small, defensible accommodations, and the goal erodes underneath them the way a coastline erodes, imperceptibly per event and dramatically over time. By the time the divergence is large enough to notice, the agent has often done substantial work in the wrong direction, and that work can be hard to distinguish from correct work because it is internally coherent. The output is not garbage. It is a competent answer to a question no one asked.

Defending against drift requires treating the original goal as something with independent standing, not as a memory that has to compete for space against everything the agent has since observed. The objective belongs in a fixed store outside the running context, written down once and referred back to, rather than left to survive only inside a window where later information steadily crowds it out. Every revised plan is measured against that written objective before it runs, so the comparison lands on the goal as originally stated and not on the goal as the agent now half-remembers it. Recording the objective next to each revision does two jobs at once: it forces the check to happen, and it leaves a trail someone can walk back later, so that when an agent does end up somewhere wrong you can find the revision that turned. Drift is subtle in flight, but it is obvious in a log that records the goal beside each plan. The instrumentation is what converts an invisible failure into a visible one.

The plan is disposable, the goal is not

The mental shift that makes all of this cohere is to stop treating the plan as the valuable thing. The plan is a hypothesis about how to reach the goal, formed with incomplete information, and it should be held loosely enough to revise the instant the environment contradicts it. What must be held tightly is the goal, because the goal is the only thing that gives any revision a standard to be judged against. A system that grips its plan too hard is brittle and breaks on the first surprise. A system that holds its goal too loosely is worse, because it bends smoothly and continuously until it is doing something else entirely, and it does so without ever appearing to fail.

Adaptive planning done well lives in the narrow band between those failures. It fires deliberately, only when a real assumption has been invalidated rather than at every minor bump. It is bounded, so that revision cannot become an infinite regress. And it is anchored, so that every new plan is measured against the objective it inherited and not against a drifting recollection of it. Guarded that way, the ability to replan is the feature that lets an agent take on goals whose path could never have been fully specified in advance. Left unguarded, it is the feature that lets the same agent fail expensively, endlessly, and convincingly. The mechanism is identical in both cases. The bounds and the anchor are the entire difference.