Examples include:
“That is no longer the goal.”
“Use the current requirement instead.”
“Do not send that.”
“This earlier assumption is wrong.”
For a long-running agent, those are not ordinary follow-up messages. They can change the meaning of work already in motion.
If a person corrects an agent after it has researched, planned, drafted, queued work, or prepared an external effect, the system must do more than place the new sentence near the end of a conversation. It needs to decide what task state has changed, which prior decisions are invalid, which artifacts remain usable, and what must happen before the task can proceed.
Treating correction as a task-state change makes that work legible.
Recent research points to the same broader need from several directions. The AgentGUI preprint focuses on observing and steering long-running agent sessions. The Online Monitoring and Corrective Steering of Programming Agents preprint, which introduces LivePlan, proposes separating detection of a trajectory problem from high-level corrective advice. The AgentRewind preprint argues for aligned checkpoints when recovering long-horizon work. These are research proposals, not universal production guidance, but together they highlight a simple product truth: a correction needs an explicit relationship to the work it changes.
Correction is not the same as interruption
An interruption answers a delivery question: should the agent stop, defer, or receive new input before its next step?
A correction answers a semantic question: which part of the task is no longer true?
The distinction matters. An agent can pause immediately after a user interrupts it and still have no idea whether the user:
- changed the objective;
- constrained the allowed tools or data;
- replaced a factual premise;
- withdrew an approval;
- rejected a proposed effect; or
- merely asked for a status update.
Only some of those changes invalidate prior work. Treating every follow-up as a total reset throws away useful progress. Treating every follow-up as a casual note risks carrying a flawed plan forward.
The system needs a middle path: identify the change and trace its consequences.
The Correction Record
The Correction Record is a proposed durable record for a correction that changes a task’s meaning or allowable next action. It is not a transcript archive. It should capture only the task-relevant fact of the correction, with the user’s privacy and the safety of the next action in mind.
- Record element: Correction identity — Question it answers: Which task-state change is this? — Why it matters: Lets later work refer to the correction without duplicating private conversation
- Record element: Authorized source — Question it answers: Who or what had standing to make this correction? — Why it matters: Distinguishes a user or approved authority from untrusted content
- Record element: Changed subject — Question it answers: Which goal, constraint, fact, approval, or intended effect changed? — Why it matters: Prevents a vague message from being applied too broadly
- Record element: Previous and current posture — Question it answers: What did the task previously assume, and what is now the governing position? — Why it matters: Creates a clear re-planning boundary
- Record element: Affected lineage — Question it answers: Which plans, evidence, drafts, tool results, or proposed effects rely on the old posture? — Why it matters: Enables targeted invalidation rather than wholesale deletion
- Record element: Preservation decision — Question it answers: What work remains valid and why? — Why it matters: Protects useful research or drafts that are independent of the correction
- Record element: Next task posture — Question it answers: Continue, re-plan, hold, ask a question, or cancel a proposed effect? — Why it matters: Makes the agent’s next move reviewable
- Record element: Resolution evidence — Question it answers: What revalidation or human acknowledgment closes the correction? — Why it matters: Prevents a correction from disappearing after a retry or handoff
The record should never store more of the original conversation than its purpose requires. In many cases, a concise description of the corrected condition and the affected task boundary is enough.
Use a lineage check before continuation
Once a correction arrives, the agent should not jump straight to a new answer. It should first trace which earlier work depended on the corrected condition.
Consider a task that has gathered sources, formed a plan, drafted a result, and prepared a proposal. A correction may invalidate:
- the goal itself, making the plan and draft obsolete;
- one factual premise, making only a cited section need revalidation;
- a tool or data boundary, making a pending action ineligible while leaving a non-sensitive draft intact;
- an approval, making a proposed effect unavailable until a new confirmation arrives; or
- a user preference, making the final presentation change while the underlying research remains useful.
The agent should make that scope visible. It can say which artifacts it is preserving, which it is marking stale, and which narrow question prevents safe continuation. This gives users control without forcing them to reconstruct the agent’s entire internal history.
The LivePlan paper is relevant here because it separates observing that a trajectory has a problem from deciding what high-level correction to give. Product teams can apply the same separation to human input: first determine what part of the task is affected, then decide whether to resume, re-plan, or hold.
Preserve valid work, invalidate dependence
A correction should be precise enough to avoid two bad outcomes.
The first is over-invalidation. If a user changes the requested format, the system should not discard unrelated verified research. If a user corrects one decision criterion, the system should not pretend that all prior evidence vanished.
The second is under-invalidation. If a correction changes a constraint that the plan relied on, the system should not retain the plan as though nothing changed. A polished answer can still be wrong if its structure rests on an invalid premise.
The right unit of change is dependency. An artifact remains usable when its claim, evidence, and permissible effect do not depend on the corrected condition. It becomes stale when they do.
This does not require a perfect graph of every token the model has seen. It requires explicit references for the decisions that matter: plans, evidence selections, durable notes, drafts, approvals, and proposed external effects.
The checkpoint idea in AgentRewind makes the value of such references easier to see. Recovery is more meaningful when the restored context and environment are aligned. A correction record adds another alignment: the task’s durable interpretation must agree with the user’s current instruction.
Let corrections alter effects safely
The highest-risk correction is one that arrives after the agent has prepared a consequential effect.
For example, a user may withdraw approval for a change, correct a destination, or narrow what may be included in an output. The system should be able to put the pending effect into a clear state such as:
- blocked pending confirmation;
- superseded by a later correction;
- re-planning required; or
- safe to continue because the correction did not affect it.
An agent should not quietly apply, delete, or reverse an external effect merely because a new message seems related. The Correction Record should identify the effect at a high level, match the correction to its authority, and require the right confirmation or review path for the next transition.
That behavior gives people something better than a generic “I updated it.” It gives them a visible account of what changed and what the agent will do next.
Design corrections as a first-class interface
The AgentGUI preprint is a reminder that supervising multiple long-running sessions is an interface problem as well as a model problem. Users need to see that a correction was received, where it applies, and whether the agent has acted on it.
A useful correction interface does not need to expose hidden reasoning. It can show:
- the task element that changed;
- the work marked stale or retained;
- the next planned posture;
- any confirmation or question that is still required; and
- the resolution when the revalidation is complete.
The interface should also preserve the ability to say, “This correction is ambiguous.” An agent that asks a narrow clarification can be safer and faster than one that guesses which of several interpretations the user meant.
A practical adoption path
- Identify which user inputs actually change task state: objective, constraint, fact, authority, or effect.
- Define a compact Correction Record with explicit dependency references.
- Add a status for artifacts that are stale but retained for review.
- Require a lineage check before a resumed task relies on prior plans, evidence, or approvals.
- Make pending effects visible and confirmation-gated when a correction touches them.
- Test corrections during execution, after a pause, after a handoff, and just before an external effect.
The outcome is not an agent that never changes course. It is an agent that can change course without losing track of why.
What we are learning building Virillio Code
Virillio Code is in development. High-level work around task boundaries, interruption, and durable state supports a general lesson: meaningful corrections should update the durable task model and trigger targeted revalidation. The Correction Record is a proposed educational framework, not a description of a released Virillio Code capability.
Sources and further reading
- AgentGUI: An Interface for Observing and Steering Long-Running AI Agents — A recent preprint presents an interface for observing and steering multiple concurrent, long-running agent sessions.
- Online Monitoring and Corrective Steering of Programming Agents — A recent preprint proposes separating trajectory monitoring from high-level corrective advice for programming agents.
- AgentRewind: Recoverable Execution for Long-Horizon LLM Agents — A recent preprint proposes aligned checkpoints for agent context and a controlled environment to support recovery after a long-horizon attempt.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.