{"id":1012,"date":"2026-09-07T11:27:41","date_gmt":"2026-09-07T11:27:41","guid":{"rendered":"https:\/\/blog.agentsarchitects.ai\/?p=1012"},"modified":"2026-09-07T11:32:21","modified_gmt":"2026-09-07T11:32:21","slug":"how-ai-agents-handle-mid-task-corrections-replanning-permissions-and-recovery","status":"publish","type":"post","link":"https:\/\/blog.agentsarchitects.ai\/index.php\/2026\/09\/07\/how-ai-agents-handle-mid-task-corrections-replanning-permissions-and-recovery\/","title":{"rendered":"How AI Agents Handle Mid-Task Corrections: Replanning, Permissions, and Recovery"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n


An AI agent is sourcing quotes from twelve suppliers. It has evaluated the first six and sent requests for quotation to four.<\/p>\n\n\n\n

Then the buyer changes the requirement:<\/p>\n\n\n\n

\u201cEU suppliers only. Keep the budget unchanged. Prepare the comparison, but do not contact anyone else.\u201d<\/p>\n\n\n\n

The agent acknowledges the instruction.<\/p>\n\n\n\n

Whether it handles the correction correctly depends on what happens next. Pending outreach must be blocked where possible. The shortlist must be revised. The budget must remain intact. Earlier messages must be accounted for, even though they cannot simply be erased from recipients\u2019 inboxes.<\/p>\n\n\n\n

Mid-task correction is the process of incorporating an authorized change after an AI agent has begun working. Reliable handling requires coordinated updates to the plan, relevant task state, permitted actions, and recovery decisions.<\/p>\n\n\n\n

The difficult question is what the system must preserve, invalidate, stop, or reconcile when its instructions change.<\/p>\n\n\n\n

Corrections can arrive during planning, research, drafting, or execution. External side effects are not a prerequisite. They make the problem more consequential.<\/p>\n\n\n\n

What changes when an agent receives a correction?<\/h3>\n\n\n\n

Some updates change inputs: \u201cUse the revised forecast.\u201d<\/p>\n\n\n\n

Some change constraints: \u201cOnly consider suppliers based in the EU.\u201d<\/p>\n\n\n\n

Some change permissions: \u201cPrepare the email, but do not send it.\u201d<\/p>\n\n\n\n

Others change the objective entirely.<\/p>\n\n\n\n

A correction can belong to several categories at once. An instruction that narrows geographic scope and withdraws permission to contact suppliers changes both the evaluation criteria and the action boundary.<\/p>\n\n\n\n

For implementation, the useful question is: which parts of the active task specification does this update supersede?<\/p>\n\n\n\n

That specification includes the objective, constraints, inputs, permitted actions, and conditions for completion. Requirements unaffected by the correction should remain active.<\/p>\n\n\n\n

Why acknowledgement does not establish compliance<\/h3>\n\n\n\n

An agent may acknowledge a correction while its next action still follows the earlier plan.<\/p>\n\n\n\n

I use \u201cplan inertia\u201d here as a descriptive label for that observable behaviour. It is not a claim about a single underlying mechanism or a newly established research construct.<\/p>\n\n\n\n

Several mechanisms could produce it. The model may misinterpret the update. A stored plan may remain unchanged. A queued tool call may execute before cancellation. A worker agent may still be using an earlier task version. A compressed memory may preserve a superseded assumption.<\/p>\n\n\n\n

These failures require different remedies.<\/p>\n\n\n\n

Research on dynamic planning offers a useful foundation. Plan-and-Act separates planning from execution and revises plans using the current state and execution history. Its authors also discuss the efficiency cost of replanning after every action. This supports adaptive planning as a design direction, without establishing that replanning alone resolves permission changes or external side effects. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks<\/a><\/p>\n\n\n\n

A correction-aware system should identify dependencies. If a supplier becomes ineligible, its exclusion may affect the shortlist, aggregate calculations, rankings, draft recommendations, and delegated work.<\/p>\n\n\n\n

Removing its name from the final answer leaves those dependencies unresolved.<\/p>\n\n\n\n

Replanning should preserve valid work<\/h3>\n\n\n\n

A complete restart can discard useful evidence and increase cost. Continuing unchanged can propagate obsolete assumptions.<\/p>\n\n\n\n

My proposed approach is to version the active task specification and associate plans, intermediate outputs, and action requests with the version under which they were created.<\/p>\n\n\n\n

When a correction is accepted, the system evaluates existing work against the new specification.<\/p>\n\n\n\n

Some work remains valid. Research on eligible suppliers may still be useful.<\/p>\n\n\n\n

Some work needs revision. Rankings and averages involving excluded suppliers must be recalculated.<\/p>\n\n\n\n

Some work should no longer influence the outcome. A recommendation based on the superseded shortlist should be marked stale.<\/p>\n\n\n\n

This is an engineering proposal, not a guarantee provided by a version number. The runtime must enforce the distinction, and incomplete dependency information may require conservative revalidation.<\/p>\n\n\n\n

Memory deserves the same treatment. Earlier instructions can remain in the historical record, but their superseded status must be explicit. Otherwise, retrieval or context compression can reintroduce them as current requirements.<\/p>\n\n\n\n

A task-specific correction should also stay task-specific. Excluding a supplier from one review does not establish a permanent preference for every future assignment.<\/p>\n\n\n\n

When does a correction become an authorization issue?<\/h3>\n\n\n\n

Every correction changes the interpretation of the task. Some also require renewed authorization checks.<\/p>\n\n\n\n

Changing a chart\u2019s colour usually does not alter the agent\u2019s authority. Expanding the recipient list, permitting an external submission, or withdrawing access to a resource does.<\/p>\n\n\n\n

Authentication establishes who submitted the update. Authorization determines whether that actor may make the requested change for this task and resource.<\/p>\n\n\n\n

A retrieved PDF, tool response, or ordinary worker-agent message should not gain instruction authority merely because it contains imperative language. Such content may describe a proposed change. Accepting that change requires a trusted route and appropriate authority.<\/p>\n\n\n\n

A deliberately authorized supervisory agent is a different case: its power to revise work must be explicitly delegated and bounded.<\/p>\n\n\n\n

The agent must not infer an expanded permission grant from conversational wording alone. Any increase beyond its current grant should pass through the applicable authorization process and remain within higher-level policy.<\/p>\n\n\n\n

This distinction allows legitimate users to revise tasks without allowing untrusted content to rewrite the system\u2019s permissions.<\/p>\n\n\n\n

The timing problem inside \u201cstop\u201d<\/h3>\n\n\n\n

A correction can arrive after a tool has started but before its result returns.<\/p>\n\n\n\n

OpenAI\u2019s mid-turn steering documentation makes this boundary explicit: receiving an update does not automatically undo earlier actions or cancel tools already running. The application must account for execution state separately. OpenAI: Mid-turn steering<\/a><\/p>\n\n\n\n

A useful action record distinguishes queued, dispatched, executing, completed, cancelled, and uncertain operations.<\/p>\n\n\n\n

\u201cUncertain\u201d matters. A timeout may mean that the response was lost after an external service completed the request. Retrying immediately could create a duplicate action.<\/p>\n\n\n\n

The runtime should record when a correction was received, when it became effective, and when relevant actions were dispatched and committed. These events help distinguish processing delays from operations already beyond the cancellation boundary.<\/p>\n\n\n\n

For controlled tools, an action gateway can check the current task version and authorization before dispatch. Where the system controls commitment, it can enforce those checks at that boundary too. Atomic coordination provides stronger protection than a separate check followed by a write.<\/p>\n\n\n\n

External services may offer weaker controls. The remaining risk requires cancellation attempts, outcome verification, and clear reporting.<\/p>\n\n\n\n

In the procurement example, messages sent under the earlier authorization are not automatically violations because the buyer later changes direction. They may create recovery work. Further outreach after the new restriction becomes effective is a different question.<\/p>\n\n\n\n

Recovery depends on what the action changed<\/h3>\n\n\n\n

Distributed systems provide a useful precedent. Garc\u00eda-Molina and Salem\u2019s 1987 paper on sagas describes using compensating transactions to address partially completed long-running transactions. Compensation need not restore every aspect of the original state. Sagas, 1987<\/a><\/p>\n\n\n\n

For agent design, I would use three practical recovery categories.<\/p>\n\n\n\n

Locally reversible work<\/strong> can be restored or revised within a controlled environment, such as a draft with version history. Reversal may still consume time or discard valuable computation.<\/p>\n\n\n\n

Compensable actions<\/strong> have a defined remedial operation, such as cancelling an eligible booking or issuing an authorized refund. Fees, records, notifications, or other consequences may remain.<\/p>\n\n\n\n

Actions with irreversible consequences<\/strong> cannot be fully undone, such as disclosing information to an external recipient. Deleting a published document may remove the live copy without removing downloaded copies.<\/p>\n\n\n\n

These categories depend on the action\u2019s state, the external service, and the consequence being considered. A booking\u2019s cancellation window can expire. A payment may permit a refund without allowing the original transaction to disappear.<\/p>\n\n\n\n

Recovery should therefore be designed around specific operations and their current state.<\/p>\n\n\n\n

Compensation also requires authorization. Permission to send a request does not automatically authorize a retraction message, refund, or account modification. A correction should not trigger improvised remediation with greater consequences than the original action.<\/p>\n\n\n\n

A practical correction protocol<\/h3>\n\n\n\n

I propose five useful correction types: refinement, retargeting, constraint change, permission change, and abort. They are implementation categories that can overlap, rather than an exhaustive taxonomy.<\/p>\n\n\n\n

For each accepted update, the runtime should record its source, scope, effective task version, and affected requirements.<\/p>\n\n\n\n

It should then block conflicting future actions where possible, reconcile outstanding operations, identify invalidated work, and construct a revised plan.<\/p>\n\n\n\n

An abort should stop further task execution and determine what recovery is appropriate. It should not automatically compensate every completed action.<\/p>\n\n\n\n

In a multi-agent workflow, the same update must reach affected workers. Returned results should retain their task version so the coordinator can revalidate them before reuse.<\/p>\n\n\n\n

A worker\u2019s outdated result may still contain useful facts. Its earlier authorization should not be treated as current merely because its computation has finished.<\/p>\n\n\n\n

The audit record should establish who changed what, when the change took effect, what had already happened, and how the system responded. Cryptographic signatures may be appropriate for a particular threat model; their presence alone does not establish correct enforcement.<\/p>\n\n\n\n

How should correction handling be evaluated?<\/h3>\n\n\n\n

Evaluate behaviour against the latest authorized task and the actions actually taken.<\/p>\n\n\n\n

InterruptBench, introduced in the 2026 preprint \u201cWhen Users Change Their Mind,\u201d examines additions, revisions, and retractions during long-horizon web navigation. It studies updated-intent success and adaptation efficiency.<\/p>\n\n\n\n

Its scope matters: the authors describe the evaluated interruptions as informational and state that they do not invalidate prior progress. The results therefore inform adaptation in that setting, without demonstrating reliable recovery from arbitrary committed actions. When Users Change Their Mind: Evaluating Interruptible Agents in Long-Horizon Web Navigation<\/a><\/p>\n\n\n\n

For deployment testing, introduce corrections before dispatch, during tool execution, after commitment, after memory compression, and during agent handoffs. Use controlled environments for operations that could create real consequences.<\/p>\n\n\n\n

I would report these proposed measures separately:<\/p>\n\n\n\n