Context Persistence for AI Agents

An agent often completes work in stages. It may gather evidence today, wait for an owner to answer a question, and continue after a source changes or an external system responds. If the next run receives only the last message, the agent must reconstruct the objective and may miss why a constraint was introduced. Persistence preserves a deliberate checkpoint: what is known, what remains open, what was approved, and what event should happen next.

This is different from asking a model to remember a long conversation. A checkpoint can identify the workflow, current state, selected sources, evidence versions, pending decisions, allowed tools, budget or time limits, and responsible roles. The next run can validate that package before proceeding. If material context has expired or authority has changed, the correct continuation may be to refresh or stop rather than to resume automatically.

A saved approval does not become a permanent license. Authority can be bound to a particular action, customer, dataset, amount, environment, and period. When any of those dimensions change, the workflow should determine whether the original decision still applies. Persistence preserves the evidence of approval and its scope; it should not widen that scope for the convenience of the next agent.

The boundary protects human decision-making. An agent may resume research, organize allowed evidence, or prepare a proposed update. A consequential step such as publishing a claim, changing customer access, committing funds, or modifying a contract still requires the current authority appropriate to that action. The memory of a prior decision informs the reviewer, but it does not replace the reviewer or the domain system that owns the result.

The same rule applies when the previous run was technically successful. Completion proves that a bounded step finished under earlier conditions. It does not prove that the evidence remains current or that the next action is authorized. A continuation check should compare the saved scope with present state and explain any difference. This keeps persistence from becoming an invisible escalation mechanism and gives the approver a clear reason when the workflow asks for renewed authority.

Ephemeral context supports a single model call or tool step. It may include a calculation, an extracted passage, or a temporary plan that can be discarded after use. Session context supports a short interaction and can retain local references or preferences while the user remains engaged. Workflow context survives a delay or handoff because the task has not reached a terminal state. It needs a checkpoint and an explicit expiry or refresh condition.

Each lifetime should receive only the information it needs. A temporary classification does not need to become durable user history. A session preference should not automatically influence another workspace. A workflow checkpoint may need a customer identifier and open issue but not unrelated account data. Matching context lifetime to purpose reduces retrieval noise and limits the amount of sensitive material that must be governed after the task ends.

Durable company records carry meaning beyond one workflow. Approved policies, product decisions, verified events, source observations, and accepted lessons may qualify. They should include record type, source lineage, owner, effective scope, sensitivity, and supersession rules. Historical evidence can preserve what occurred without remaining authoritative for current action. That distinction lets the company explain the past while operating from the present.

A hypothetical procurement workflow shows the difference. A supplier quote can be working evidence for a current comparison. The approved selection becomes a decision record. The signed agreement remains authoritative in its domain repository. A later service issue becomes an event. If the agreement expires, the memory layer can preserve its historical role while preventing an agent from using it as current purchasing authority.

A checkpoint should identify the objective, current stage, completed actions, pending items, source versions, relevant outputs, unresolved uncertainty, permission scope, owner, and next allowed transition. It should also record the conditions that invalidate the package, such as a policy update, an expired approval, a changed customer state, or a failed external action. This makes resumption a validation step rather than blind replay.

Consider a hypothetical public-content review. An agent collects sources and prepares a draft, but a security claim requires specialist review. The checkpoint records the unsupported claim, source coverage, reviewer, and publication hold. When work resumes, the next agent can update the draft after the decision without treating the prepared copy as approved. If the cited source changed in the meantime, the workflow refreshes evidence before requesting release authority.

Persistence can create duplicate action if a resumed agent cannot tell whether the previous attempt succeeded. External calls should use an idempotency strategy or a reliable action receipt where the system supports it. The checkpoint should distinguish proposed, requested, accepted, completed, refused, failed, and unknown states. Unknown is important: a timeout does not prove that an external system did nothing.

An append-only event history can support reconstruction, but current workflow state should be derived through defined rules rather than inferred from the latest readable sentence. Events need identities, sequence, actor, environment, and correlation to the initiating request. Corrections may append a new event while a current-state view makes the corrected posture clear. The design should preserve evidence without forcing every consumer to replay an unbounded history.

Before retrieval, the system should know who or what is requesting context, which workspace and subject are in scope, what action is proposed, and what level of consequence it carries. These attributes determine which collections may be searched and which record types may be included. Freshness checks can then identify sources that require validation before use. Filtering after generation is too late when restricted material has already entered model context.

Purpose also shapes ranking. A historical analysis may legitimately retrieve superseded records, while a current customer response should prefer approved present guidance. An internal planning workflow may include uncertain hypotheses that a public communication workflow must exclude. The assembler should record these selection rules and expose conflicts rather than asking the model to decide whether sensitive or outdated material is acceptable.

A context package can include the objective, current workflow state, selected source references, relevant excerpts or structured facts, prior decisions, unresolved questions, authority boundary, and expected output. It should distinguish source material from generated summaries and identify the versions used. This creates an inspectable boundary that can travel through a handoff without granting broad repository access to every downstream agent.

The package should also be bounded by size and duration. If too many records appear relevant, the workflow may need a narrower question or a preliminary discovery step. If the package expires before the next action, it should be refreshed against authoritative sources. Context persistence is not a promise that yesterday's evidence remains correct; it is a mechanism for preserving and revalidating what yesterday's workflow actually used.

Context drift occurs when a workflow resumes from a valid old checkpoint after the underlying company state has changed. State collision occurs when two agents continue the same work and produce incompatible updates. Orphaned work remains active after its owner or lease disappears. Partial completion occurs when one system accepts an action but the local workflow records a failure. Each condition requires a different response, and none is solved by giving the model a longer transcript.

Controls can include version checks, leases, compare-and-set updates, explicit ownership, action receipts, bounded retries, and terminal-state reconciliation. The system should detect when a checkpoint no longer matches current state and route the difference for review. A recovery process may continue, compensate, or abandon the work. It should not overwrite evidence simply to produce a clean status.

Persistent context can carry malicious instructions or accidental errors farther than one run. Untrusted documents may contain prompt-injection attempts, and generated summaries may overstate uncertain source material. Source classification, instruction-data separation, allowlisted tools, provenance display, and review for high-impact updates can reduce the risk. These controls do not create an absolute security guarantee.

Privacy obligations also shape persistence. A company should define why a data category is retained, who may access it, how corrections and deletion propagate, and what derived indexes or summaries exist. The appropriate policy depends on the data, contracts, jurisdiction, and organizational requirements. An agent architecture should enforce approved policy and provide evidence for review; it should not invent retention periods or legal conclusions.

Create scenarios that pause at meaningful transitions: before approval, after an external request, during a source update, and after a denied permission. Resume with the same agent, a different agent, and a human operator. Verify that each sees the appropriate state and evidence. Change a source, expire an approval, revoke access, duplicate a callback, and introduce a conflicting update to test whether continuation stops or reconciles safely.

Review the resulting evidence. The system should show which checkpoint was loaded, which validation occurred, what changed, why the next transition was allowed or refused, and who resolved uncertainty. Measure duplicate actions, stale resumes, abandoned workflows, correction time, review burden, and successful recoveries. A technical resume rate is not enough if resumed work uses inappropriate context or hides unresolved external state.

OmegaOS treats persistent context as part of an operating loop that connects work, authority, evidence, and learning. Mnemosyne - MemoryOS provides the conceptual path for durable source and lineage records, while a bounded context package can carry an approved selection into the active workflow. The authoritative domain source remains distinct from the context used to help an agent reason or prepare action.

A responsible first implementation selects one workflow with repeated interruptions and a clear owner. The team defines checkpoint states, authoritative sources, allowed users, expiry rules, action receipts, correction paths, and an observable outcome. It should verify the exact product and connection posture for the intended configuration. Expansion is justified only when resumption remains useful under change and the privacy, review, and maintenance burden stays proportionate.