A plan is usually written as if it will be executed immediately.
Long-running agents break that assumption.
An agent may create a plan, wait for an external system, receive a new user instruction, delegate a subtask, encounter a partial result, or resume after time has passed. The plan is still present in memory or durable storage. That does not mean it is still valid.
A plan is not a promise to execute. It is a hypothesis about what actions will remain appropriate if its assumptions continue to hold.
The difference matters whenever agents act in changing environments. A once-valid plan can become stale in a harmless way, such as a search query that now needs an updated source. It can also become stale in a consequential way, such as a planned external action whose target, authority, or prerequisite has changed.
The system should not solve this by replanning constantly. It should make the plan's validity conditions explicit enough to know when re-evaluation is warranted.
Why plans go stale
Plans can become stale even when the user has not changed their request.
- Change source: Environment state — Example: A file, record, issue, or external resource changes — Why the plan may no longer be safe or useful: The planned action may be based on an obsolete observation
- Change source: Other workers — Example: A subagent completes, fails, or discovers a conflict — Why the plan may no longer be safe or useful: Dependencies and task ordering changed
- Change source: User direction — Example: The user narrows, redirects, or interrupts the work — Why the plan may no longer be safe or useful: The original objective or authority boundary changed
- Change source: Policy and capability — Example: A permission, policy, or workspace boundary changes — Why the plan may no longer be safe or useful: The agent may no longer be allowed to execute the action
- Change source: Time — Example: A deadline, reservation, or freshness-sensitive fact passes — Why the plan may no longer be safe or useful: The evidence that justified the plan has expired
- Change source: Uncertain outcome — Example: A previous tool call returns partial or unknown status — Why the plan may no longer be safe or useful: The next step must verify state rather than assume the old plan remains correct
The recent SyncPlan preprint provides a useful research example: it describes one-shot coordination plans as vulnerable to becoming stale in a changing environment and studies a detector that triggers selective replanning when its assumptions no longer hold. Its results are specific to the environments evaluated, but the design question is general: when should a system reuse a plan, and when should it stop treating it as current?
The plan-validity envelope
A plan needs more than steps. It needs a compact record of the conditions that make those steps legitimate.
- Part: Objective and non-goals — Question it answers: What is this plan trying to achieve, and what must it not expand into? — Example content: User-visible outcome, acceptance criteria, prohibited effects
- Part: Observation references — Question it answers: Which facts were used to create the plan? — Example content: Stable artifact references, source timestamps, task snapshot identifiers
- Part: Preconditions — Question it answers: What must still be true before a step runs? — Example content: Required input exists, target has not changed, approval remains valid
- Part: Dependencies — Question it answers: Which worker, artifact, or external state must settle first? — Example content: Completion condition, ownership boundary, wait or verification requirement
- Part: Freshness and invalidation rules — Question it answers: Which events make the plan or a step stale? — Example content: New user input, changed target, elapsed window, failed verification, policy change
- Part: Response to invalidation — Question it answers: What happens when the plan is no longer valid? — Example content: Re-read state, re-plan, ask a focused question, transfer, or stop with a truthful handoff
This is a proposed architecture model, not a claim that every task needs a formal planner. The envelope can be a few structured fields on a high-value workflow. Its purpose is to make the assumption behind an action visible at the point of execution.
Precondition every consequential step
Not every thought needs a freshness check. Every consequential action does.
Before an agent performs a material effect, it should ask:
- Is the user-visible objective still the same?
- Does the current target match the one that the plan examined?
- Are the relevant observations still current enough for this action?
- Have dependent workers or tools produced information that invalidates the next step?
- Is the authority boundary still valid for this exact effect?
- What evidence will verify the action after it happens?
This is not a request for a model to narrate a long private chain of reasoning. It is a bounded system check. The result can be a simple decision: proceed, refresh state, re-plan, ask, or stop.
A plan with no named preconditions invites open-loop execution. A plan whose preconditions are too detailed becomes impossible to maintain. The right level is the smallest set of facts that would change the legitimacy or expected outcome of the next important action.
Refresh plans at boundaries, not continuously
A common reaction to staleness is to call the model again before every action. That can add cost and still fail to identify the relevant change.
A better pattern uses boundaries.
- Boundary: Before a consequential tool call — What to check: Target, authority, current task state — Typical response: Proceed only if the effect remains within the plan envelope
- Boundary: After a partial or unknown result — What to check: Actual external state and evidence — Typical response: Verify, revise the plan, or surface a truthful pending state
- Boundary: After a worker handoff — What to check: Dependency result, ownership, and changed assumptions — Typical response: Merge evidence and re-plan only the affected branch
- Boundary: After a user message or policy update — What to check: Objective, non-goals, and approval state — Typical response: Replace or invalidate the affected portion of the plan
- Boundary: After a long wait or resume — What to check: Freshness-sensitive observations and deadlines — Typical response: Re-read named state before continuing
- Boundary: Before claiming completion — What to check: Acceptance criteria and verification evidence — Typical response: Check the result, not just whether every planned step ran
This preserves the efficiency benefit of planning while preventing a plan from becoming an unattended script.
Anthropic's engineering account of multi-agent research describes open-ended research as inherently dynamic: new discoveries can change the next direction of inquiry. That is a strong reminder that a plan should guide exploration, not suppress relevant evidence that appears after the plan was written.
A stale plan is not always a failed plan
Invalidation should be informative, not punitive.
- Invalidation result: A precondition is unchanged — Correct interpretation: The plan is still eligible — Next action: Continue with the next bounded step
- Invalidation result: A nonmaterial fact changed — Correct interpretation: The plan may need a local adjustment — Next action: Update the affected step and retain the rest
- Invalidation result: A material dependency changed — Correct interpretation: The planned path may be invalid — Next action: Re-plan the affected branch from current evidence
- Invalidation result: Authority or user intent changed — Correct interpretation: The system no longer has a valid basis to act — Next action: Ask for a new decision or stop
- Invalidation result: State is unknown — Correct interpretation: The plan's assumptions cannot be trusted — Next action: Verify actual state before retrying or continuing
This prevents an all-or-nothing failure mode. Replanning should be selective when only one branch is stale, and comprehensive when the objective or authority boundary has changed.
Separate plan freshness from context freshness
Context and plans are related but not identical.
A context-refresh mechanism asks, “What information should the model see for its next turn?” A plan-validity envelope asks, “Which action remains justified by the evidence and authority we have now?”
A model can receive fresh context and still execute an old plan without checking whether the new information invalidates it. Conversely, a plan can remain valid even if the model's conversation history was compacted, provided its key observations and preconditions are represented by durable references.
Keeping the concepts separate makes both systems simpler:
- context management keeps model reasoning relevant;
- plan validity keeps agent action legitimate;
- verification tests whether the result matches the plan's intended outcome;
- authority leases ensure a valid plan does not exceed user or policy consent.
Five anti-patterns
Treating a plan as a queue of commands
A plan is not a script that becomes correct by being executed in order. It is a set of proposed actions under conditions.
Replanning without stating what changed
Blindly generating a new plan can hide the causal reason for the change. Record the invalidated precondition or new evidence so reviewers can see why the old plan stopped applying.
Checking state only after the effect
Post-action verification is essential, but it cannot replace a precondition check for an action that should not have occurred.
Keeping stale plans in context as if they were instructions
A historical plan may be useful evidence. It should be labeled as superseded or tentative, not left beside current instructions with equal authority.
Asking for reapproval on every harmless adjustment
Too much friction makes people bypass the process. Escalate when the target, scope, effect, or policy boundary changes materially; let local, reversible adjustments remain within the existing envelope.
Measure plan-validity quality
Teams can evaluate whether their plans remain useful in the real world:
- Precondition coverage: What share of consequential actions had a named, checkable precondition?
- Staleness detection: How often did the system catch a changed assumption before it caused an incorrect action?
- Selective replan rate: Did the system revise only affected branches when appropriate?
- Unnecessary replan rate: How often did it discard a still-valid plan without new evidence?
- Authority alignment: Did plan changes trigger a new decision when the approved effect changed?
- Completion truthfulness: Did the final status reflect verification and current state rather than merely completed plan steps?
These measures favor systems that remain adaptive without becoming chaotic.
A practical adoption path
- Choose one long-running workflow where state can change between planning and execution.
- List the smallest set of facts that would invalidate its next material action.
- Add objective, observation references, preconditions, dependencies, freshness rules, and invalidation response to the plan record.
- Check that envelope at handoffs, resumes, and consequential effects.
- Record the specific event that triggered every material replan.
- Keep old plans as labeled historical evidence, not as active instructions.
- Compare error and rework outcomes before and after the stale-plan check.
The goal is not a perfect plan. It is a plan that knows when it has stopped being one.
What we are learning building Virillio Code
Virillio Code is still in development. One general design lesson is that preserved state is useful only when a system can recheck whether it remains current. A plan-validity envelope makes that question explicit before a long-running agent turns an earlier hypothesis into a later action.
Sources and further reading
- SyncPlan: Long-Horizon LLM Coordination with Explicit Synchronization and Adaptive Correction — A recent preprint frames one-shot plans as vulnerable to environmental change and studies selective stale-plan detection and replanning in evaluated dynamic multi-agent environments.
- How we built our multi-agent research system — Anthropic — Open-ended research is dynamic and benefits from independent exploration paths that can adapt to intermediate findings.
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.