Check the plan around an agent’s repair

A failed tool call can leave most of an agent’s plan usable. If one step cannot complete, an agent may be able to replace that part while keeping useful earlier and later work intact. A paper published on 7 October presents Plan-and-Patch, which fills a selected section of a structured plan while conditioning on surrounding steps.

That is a new recovery option for long tasks. Its boundary is the part of the plan that can be changed without making the retained steps stale. A replacement that fits the text around it may still alter the assumptions those steps depend on. The architecture decision is therefore when a local repair can resume and when the agent must hold, replan or ask a person.

Give each step a checkable place in the plan

The paper represents a plan as a hierarchy of subgoals and executable steps, each with an identifier, action, arguments and expected observation. After failure, its executor uses the action history and environment feedback to select a repair region. The planner fills that region while conditioning on the retained plan.

Masked diffusion can generate plan tokens in parallel from context on both sides of a gap. The study also compares an autoregressive model trained for fill-in-the-middle repair.

Stable step identifiers give the surrounding workflow something specific to inspect. A repair record can name the failed step, the observation that triggered revision, the plan and environment versions, the replacement, and the steps whose assumptions may have changed. This record is an architectural recommendation inferred from the framework. The paper does not provide an enterprise plan ledger.

Recheck the steps that depend on the change

Consider a hypothetical purchasing workflow. An agent checks a catalogue, selects an approved supplier, checks the price against an authorised limit, prepares an order and sends it for approval. The catalogue reports that the selected supplier has no stock. A replacement supplier may preserve the goal, but its price and delivery date may differ. The later checks remain in the plan, yet their earlier results no longer apply.

In this case, the replacement step should not release the order. The workflow should repeat the price and delivery checks against the new catalogue result, then pass the updated draft through the existing approval boundary. If the failure leaves the actual stock or order state uncertain, hold the task until the owner can reconcile that state. A plan rewrite changes the instruction record. A separate transaction or reconciliation mechanism must resolve any effect that already reached a business system.

The paper’s repair-region results make selection a separate design concern. On the same 175 eligible failed tasks, using execution history to select the region reduced pooled repair success compared with reference-assisted selection: 12 percentage points for diffusion and 8.6 for the autoregressive model. A model that can fill a replacement does not determine which steps should change.

illustrative fixture

Check what remains valid before resuming

Swipe or scroll for the full diagram →

What must be true before an agent continues after a plan repair?

Owner: Workflow owner and authorised execution boundary. Threshold: The failed effect is contained or known, the repair region has a recorded cause, and later steps still meet their preconditions.

Expand

Repair the smallest supported region and retain stable step identifiers, the state version and prior action records.

Retain narrower scope

Pause dependent effects and replan the subgoal or ask a person when the cause or task state remains uncertain.

Gather more evidence

Check the repaired step and every retained step that depends on it before allowing the next external effect.

For a first trial, limit automatic continuation to a sandbox or to actions whose effects are known and reversible. Require checks for the repaired step and every retained step that depends on its output. Pause before an external effect when the region, current state or dependency is unclear. That gate gives the system a defined route for uncertain recoveries without turning model-generated text into permission to act.

Measure recovery separately from planning speed

Plan-and-Patch tests generation and repair on ALFWorld household tasks and TextCraft dependency-based crafting. Its reported generation measurements show a 39 to 46 per cent reduction in mean latency for unbatched bfloat16 decoding on one A100. Prompt construction, parsing and environment execution are excluded.

The latency figure is a model-generation measurement, not a recovery-time estimate. Repair success varied with the task and the selected region. Each repaired plan was executed again from its initial state, so the study does not test recovery after an irreversible action in a live system.

An evaluation should therefore compare three routes on the same recorded failures: replace a bounded region, regenerate the affected subgoal, and restart the whole plan. Hold the starting state and failure evidence constant. Measure whether the plan parses, whether completed steps remain valid, whether dependent checks pass, and whether the task completes. Include region selection, validation and execution in the elapsed time. The paper’s generation timing excludes these costs.

The architecture owner can begin with a simulated workflow where the step conditions and effects are inspectable. If local repair reduces recovery time without increasing stale actions or failed checks, expand the trial to a tightly bounded, reversible operation. Keep approval requirements attached to the effect itself. A faster patch is useful when the workflow can show why the changed step and the work after it still fit the current state.