When You Correct an AI Agent, What Should It Recheck?

When a user corrects an AI agent, the agent should identify which earlier work relied on the wrong fact. It should then revise those outputs and repeat the checks that are no longer valid. Reassuring the user while continuing from the same assumptions is not a correction.

The method below keeps the original objective in place. It addresses changed facts or requirements, not simply a new order of priorities. It is a proposed workflow, reviewed September 12, 2026; the examples are illustrative and no agent compliance experiment was run.

Suppose an agent is preparing a product launch package and the user corrects the target audience from existing customers to first-time buyers. The objective remains a launch package, but the audience assumption changes. Copy, examples and required explanations may now need review even if the layout still works.

Capture the correction in plain language: what was previously understood, what is now required and where it applies. If the user says a number is wrong without providing the replacement, the next step is to verify it or ask for the missing value. Do not invent the correction to avoid a question.

Distinguish a verified factual update from a user preference. Both can change the work, but a user hypothesis about an external fact may still need evidence. Keep the source or authority beside the change so that a later summary does not turn an unresolved suggestion into an accepted requirement.

Use the table to identify direct outputs, derived outputs and evidence that may have become stale. The categories are proposed review decisions, not a claim that a model automatically computes a complete dependency graph. They work best when the task already records where important facts were used.

Start with the smallest affected set, then follow its downstream uses. A corrected price can affect a comparison, a recommendation and the metadata that summarizes the recommendation. Merely fixing the visible price leaves the earlier conclusion unsupported.

Acceptance evidence belongs to a particular version of the work. A screenshot of yesterday's page cannot verify today's revised copy. A passing calculation check against the old input does not establish that the corrected output is accurate. Record the version or timestamp needed to tell those apart.

For the launch-package example, inspect the introduction, feature explanations and examples for assumptions about prior product knowledge. Keep the visual structure if it remains suitable. Then review the actual revised package against the new audience, rather than asking the agent whether it understands the correction.

The LangGraph interrupt documentation shows how human input can edit state before work resumes. That is a mechanism for receiving a correction. Deciding which derived artifacts and checks to revisit remains an application and workflow responsibility. The documentation should not be read as a guarantee of complete semantic invalidation.

Consider an illustrative report that compares suppliers. The user corrects the required service region. The relevant supplier eligibility and recommendation need rechecking. The report's citation formatting may remain valid. An unrelated accessibility fix in the report viewer may also remain valid, provided it does not depend on the changed content.

The agent should explain these boundaries briefly and then do the work. A useful acknowledgment states the corrected requirement, the affected outputs and the next check. It should not force the user to restate the original objective or approve routine revisions they already requested.

The Astra instruction guide covers standing project rules. Use those rules for recurring behavior, while keeping this task's correction in its own current record. A one-off audience change should not silently become a permanent preference for every future project.

An in-flight operation may have already used the old requirement. Attach the task revision to the requested operation and compare it when the result returns. An old read result might still be useful as historical evidence, but it should not silently overwrite the corrected working state.

State editing and time travel also require care around side effects. The LangGraph time-travel guide provides runtime facilities for revisiting execution. Restoring graph state does not itself reverse a document already sent or an external record already changed. Reconcile those outcomes before retrying or applying a compensating action.

Our delivery-state reference helps describe the result accurately. Drafted, saved and sent are different states. If the incorrect version was already delivered, report that fact and identify the authorized correction path. Do not rewrite the task history to make the earlier delivery disappear.

A proposed test set should include a correction before work starts, after a draft exists, while a tool is running and after an external action completes. Use a controlled environment and harmless test data. The goal is to inspect the workflow's response, not to create real customer mistakes for the sake of evaluation.

For each case, check that the agent uses the new requirement, revisits dependent outputs and preserves unrelated valid work. Check that late results do not revive the old assumption. Retain cases where the system cannot establish an external outcome; an honest unknown is better than a false completion claim.

The combined-change verification guide covers another source of stale evidence: individually valid changes that fail together. For a correction workflow, keep the final review tied to the current combined artifact. AI transformation work should make this acceptance boundary part of the design.