An agent may begin a task under one set of constraints and finish it after those constraints have changed.
The change might be ordinary: a tool becomes read-only, an approval requirement becomes stricter, an allowed data class becomes narrower, or a policy owner updates a rule. The task may be paused for minutes or days. It may move between workers. It may be resumed after a user correction. If the system cannot say which constraints applied at the last consequential decision, it cannot reliably tell whether continuing is still justified.
This is why a long-running agent needs a policy snapshot.
A prompt can give the model instructions for a turn. It is not, by itself, a durable statement of the policy that governed a past decision. Prompts can be regenerated, shortened, reordered, or updated. They can also contain information that should never be copied into an audit record. What a durable task needs instead is a compact, privacy-conscious description of the governing rules at its important decision boundaries.
Policy continuity is different from prompt persistence
Open Policy Agent distinguishes policy from the bundle revision used at evaluation time: bundles can carry a revision identifier and metadata. Its decision-log documentation illustrates the complementary need to connect a decision with the policy and data context that informed it, while emphasizing that sensitive input must be masked before a record leaves the boundary.
Agent systems need the same distinction at a higher workflow level.
The question is not “What words happened to be in the context window?” It is:
What policy identity, scope, and effect boundary justified this task transition at that time?
That question becomes material whenever an agent is about to:
- use a new class of tool;
- read or retain a different class of data;
- turn a draft into an external effect;
- resume after a meaningful delay;
- apply a user correction that changes the task; or
- carry work across a policy or environment update.
Without a durable answer, a later worker may treat an old permission as current, recreate a result under a different rule, or silently continue a task whose scope has changed.
The Policy Continuity Record
The Policy Continuity Record is a proposed design record for a consequential task transition. It is deliberately not a copy of private policy text, a hidden instruction set, or raw decision input. It is an auditable description of the policy posture that mattered.
- Record element: Policy identity — Question it answers: Which governing policy family applied? — Safe representation: A stable public or internal-safe policy label
- Record element: Revision and effective state — Question it answers: Which version or revision was evaluated, and when? — Safe representation: Revision identifier, effective timestamp, or approved change record
- Record element: Scope — Question it answers: Which task, data class, tool class, or effect class did it govern? — Safe representation: Category-level scope, never unnecessary raw content
- Record element: Allowed transition — Question it answers: What was the task allowed to do next? — Safe representation: Read, draft, propose, hold, request confirmation, or apply a narrowly defined effect
- Record element: Required condition — Question it answers: What had to remain true before the transition? — Safe representation: Current approval, matching user intent, evidence threshold, or valid authority
- Record element: Sensitivity posture — Question it answers: What must be excluded from the durable record? — Safe representation: A masking, retention, or redaction classification
- Record element: Re-entry rule — Question it answers: What must be checked before work resumes? — Safe representation: Re-evaluate, compare revisions, request review, or remain on hold
- Record element: Decision lineage — Question it answers: Which task state and decision does this record describe? — Safe representation: A task and decision reference without reproducing sensitive payloads
The record is a bridge between two moments: the moment a decision was permitted and the later moment when the system considers relying on it again.
Its value comes from being small enough to compare. A system should be able to ask whether the current policy is equivalent, broader, narrower, incompatible, or unknown relative to the snapshot. If it cannot make that comparison safely, the task should not pretend that an old decision remains authorized.
Make policy drift an explicit task event
Policy drift should be handled as a task-state event, not as background noise.
When a task resumes, the system can compare the Policy Continuity Record with the present policy posture:
- Equivalent: The governing scope and required conditions are materially unchanged. The task can continue while retaining the record for later review.
- More restrictive: The current policy narrows data access, tool use, or allowed effects. The task should stop at the boundary and re-plan within the narrower scope.
- More permissive: The system should not silently expand what the task does. It may continue under the older, narrower scope or ask for a fresh decision.
- Incompatible or unknown: The task should enter a legible hold state. A policy owner, user, or independent reviewer can decide whether a new task state is needed.
This is not an argument for freezing every workflow whenever a policy changes. It is an argument for knowing which changes matter to the work already in motion.
The AgentRewind preprint makes a related recoverability point from a different angle: long-horizon recovery benefits from checkpoints that align agent context with a controlled environment. For agent builders, policy is one of the environments that can change. A context checkpoint without a policy comparison can restore an old plan into a new set of constraints.
A snapshot is not a permission cache
The most important constraint is that the record proves neither future authorization nor a right to bypass review.
A policy snapshot says, “This is why the prior transition was permitted.” It does not say, “Repeat that transition forever.” A valid design should re-check things that are inherently current:
- a user approval that may have been withdrawn;
- an authority lease that may have expired;
- a tool scope that may have changed;
- a source that may now be stale; and
- a safety condition whose facts no longer hold.
That separation prevents a common failure mode: treating historical correctness as present authority.
The record also helps make conservative behavior useful. Instead of a generic refusal or unexplained restart, an agent can say that a policy-relevant condition changed, identify the task boundary it affects in non-sensitive terms, and propose the narrowest safe next action. The reviewer does not need a copy of private policies to understand that the task needs revalidation.
Keep the record privacy-conscious
The phrase “policy snapshot” can tempt a team to store everything. That would be a mistake.
Decision records may contain sensitive details, and the OPA decision-log guidance explicitly addresses masking sensitive fields. A durable agent record should follow the same principle:
- store an identifier and scope before storing full policy text;
- store category-level reasons before raw user or tool payloads;
- record that a condition was verified without retaining unrelated personal data;
- retain only as long as the recovery, audit, or user-control purpose requires; and
- make access to the record no broader than the task itself requires.
Privacy-preserving records are more likely to be usable across workers, review systems, and future versions of an agent. They are also easier to explain to users.
How to introduce policy continuity
Teams can begin with one workflow that has a meaningful pause or external effect:
- Identify the few task transitions where policy actually changes the allowed next step.
- Define a compact Policy Continuity Record for each transition.
- Decide which fields can be compared automatically and which require a hold.
- Add a resume check that evaluates current policy against the stored record.
- Test restrictive, permissive, incompatible, and unknown policy changes.
- Review whether the record includes more data than its recovery and accountability purpose needs.
The point is not to turn every agent into a policy engine. It is to keep durable work accountable when the rules around it evolve.
A general lesson for long-running workflows
For teams designing long-running agent workflows, the general lesson is that a task should preserve the reasons it could proceed without treating those reasons as a permanent grant. The Policy Continuity Record is a proposed educational framework, not a description of a shipped Virillio Code capability.
Sources and further reading
- Bundles — Open Policy Agent — Policy bundles can carry a revision and metadata, making a governing policy version identifiable rather than implicit.
- Decision Logs — Open Policy Agent — A decision record can be linked with evaluated policy and data context, while sensitive input needs masking.
- AgentRewind: Recoverable Execution for Long-Horizon LLM Agents — A recent preprint proposes aligned checkpoints for agent context and a controlled environment to support recovery in long-horizon work.
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.