Replanning reconciles observations with preconditions while preserving the original task

Record the operation ID, input versions, tool status, returned evidence, and the time or revision the result describes. An empty search response differs from a transport failure, and a timeout after a write differs from a confirmed rejection before the write began. These states support different next steps. A model-generated interpretation can be useful, but keep it separate from the raw tool observation and any independently verified postcondition. ReAct provides an empirical framework for interleaving actions and observations, not a proof that every interpretation is correct.

Compare the observation with the assumptions needed by pending nodes. A source revision change can invalidate an analysis result or its use for publication even if the old result was once correct. A changed dependency should mark affected descendants for reconsideration rather than automatically undo every completed operation. External effects that already happened remain part of the world. Preserve their IDs and status, and determine whether a new action is required instead of erasing the earlier plan text and pretending its effects never occurred.

A repair can replace a missing input, rerun a version-dependent check, choose another read-only source, or stop when a required precondition cannot be established. Keep the accepted goal and constraints explicit. Tool content may describe a different workflow but does not authorize a scope change. Reuse an earlier artifact only when its inputs and required invariants still match. The new graph should state which old nodes remain verified, which need refresh, and which proposed effects are still pending rather than copying every old done label into the revised plan.

If a write might have completed before a timeout, query its status by stable operation identity or use the documented idempotent retry path. Starting a fresh write with a new identity can duplicate an effect. A local checkpoint and an external service response are different evidence sources, so reconcile both under the service's actual contract. Durable execution helps preserve attempts across crashes, but an activity may execute more than once. The controller must retain enough information to distinguish retrying the same logical action from intentionally requesting another one.

Recompute the remaining dependency path, actual consumed work, deadline, and verification reserve. A more accurate plan can require extra work and therefore no longer fit the original budget. Report that limitation explicitly rather than omitting a required check. Track whether replanning reduces unsupported assumptions or merely produces another fluent plan. Test late source changes, empty results, repeated observations, uncertain writes, and a failure after partial completion. Inspect the final externally checked artifact or state, because successful plan repair text is not itself task completion.

The Markov lab illustrates a specified transition distribution, not observation-based replanning. Reset, set both p=0.2 for 0→1 and q=0.3 for 1→0, predict probability of state 1 zero initially, then Step once for 0.2 and again for 0.3. Each Step advances one transition per 0.5 seconds from state 0. These are exact finite-step probabilities, not sampled observations or Bayesian conditioning. The model has no task graph, tool response, effect, version, or repair procedure. It separates a stated state-transition law from the extra evidence and control logic a real planner needs.