Markdown

Always-on agents: persistent state, governance, and the AOEP protocol¶

Scope: a diagnostic framework for an LLM agent's durable state, memories, task ledgers, permissions, credentials, provenance and audit records, shared state, and trigger conditions, from "Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents" (Ding, Nannapaneni, Liu, Zhang; arXiv:2606.30306, June 2026). It gives six axes to characterize any state item, a ten-stage lifecycle those items move through, and AOEP-v0, a pilot protocol that scores whether state was governed rather than whether an answer was right. It sits alongside context and memory as the governance layer for what that page calls long-term memory, and next to governing self-modifying agents and identity and access on the security side.

The validator code below is a reference implementation built from the fields and rules the paper assigns each invariant (Sections 4.1.1 and 9.3), not the paper's own harness (unpublished at review time). This is a single June 2026 survey with one pilot over local 3B to 8B readers; treat its corpus counts and pilot table as a scoped, citable data point, not a benchmark leaderboard or a claim about production memory products.

What it is¶

The survey's unit of analysis is persistent state, not memory. It treats an always-on agent as a persistent-state system whose durable records include retrievable memory but also task ledgers, permissions, credentials, provenance and audit trails, shared and social state, and trigger conditions, anything whose presence today can license the agent's behavior tomorrow.¹ Each state item is modeled as a typed record

s = <v, a, c, m, p, r, k, tau>

where v is the value, a is the authority that permitted it to influence action, c is its scope, m is a mutability class (revisable, supersede-only, decaying, locked), p is a provenance chain, r is a recoverability handle linking s to the decisions it influenced, k is an actionability type (evidence, preference, policy, skill, executable commitment), and tau is a logical timestamp. Most memory systems represent only v explicitly; the other seven fields are the "governance envelope", and a system that discards it cannot recover the governance state later even if it preserves v perfectly.¹

The corpus behind these claims is 435 coded works, gathered from arXiv (cs.AI, cs.CL, cs.LG, cs.CR), Semantic Scholar, OpenReview, and the ACL Anthology across 2023 to 2026, treated explicitly as "a scoped map rather than an exhaustive census".¹

The six state axes¶

Each state item is scored along six diagnostic axes, phrased as a question an evaluation can ask of it:²

Axis	Question it asks	Invariant it grounds	Coverage in the 435-work corpus
Authority	Who or what permits this state to influence an action?	Authority monotonicity	72/435, the rarest axis
Scope	Which user, task, tool, time window, or group may it be used for?	Scope non-expansion	not separately tallied in the extracted table
Mutability	Can it be revised, superseded, decayed, or locked, and on what timescale?	(feeds update/forget)	160/435, the most common axis
Provenance	Which source, timestamp, and transformation chain produced it?	Provenance preservation	not separately tallied in the extracted table
Recoverability	Can the derived state and decisions it caused be rolled back?	Rollback traceability	112/435
Actionability	What kind of object is it: evidence, preference, policy, skill, or executable commitment?	(sets the bar for the others)	not separately tallied in the extracted table

The skew is the paper's central empirical claim: "the literature attends most to axes whose failures are internal and revisable and less to those whose failures license an action that cannot be taken back."²

Why use it¶

State becomes authoritative, not just informative. A stored preference can silently fix a tool call's default arguments; a cached credential can grant access long after a user meant it to lapse; a procedural skill learned from one trajectory can be replayed as a commitment in a situation it no longer fits.¹ None of this is repaired by filtering the current prompt, because the harm already resides in durable state.
A precise vocabulary a benchmark can perturb. The six axes are phrased so an evaluation can target one axis at a time (revoke authority, widen scope, corrupt provenance) rather than scoring memory as an undifferentiated blob.
A quantified, reproducible literature gap. Coding all 435 works by which of the ten lifecycle stages they exercise gives: retrieve 269, write 200, act 141, organize 128, update 127, audit 88, validate 87, observe 68, forget 66, rollback 27.³ Retrieval dominates; rollback, the operation that closes the loop by repairing a state-caused decision, is the rarest capability in the corpus.
A protocol that catches what recall metrics cannot. AOEP's own pilot (below) shows three memory designs (recency, full-context, dense retrieval) scoring identically on governance obligations despite very different retrieval strategies, because none of the three has a field in which to store a permission epoch or a deletion ledger in the first place.

When to use it (and when not)¶

The survey gives an explicit boundary decision procedure (its Table 6): a system is in scope for this framework when it has persistent identity, owns mutable durable state, and can use that state for later action.⁴

System	In scope?	Why
Long-context QA over supplied history	No	Context is supplied for one inference; ordinary context privacy applies
Read-only RAG over a curated corpus	No	The agent reads but does not own or mutate the corpus
Episodic ReAct or AppWorld task	No	Identity and state reset at the task boundary
Saved conversational memory	Yes	User facts persist and shape later responses
MemGPT/Letta-style external memory	Yes	The agent writes and retrieves durable memory
Repository-memory coding agent	Yes	Project conventions and prior fixes affect later edits
Calendar or trigger agent	Yes	Stored conditions cause later proactive action
Shared workspace or credentialed tool agent	Yes	Multiple principals or durable grants affect later side effects

Use this framework once your agent crosses that line: it writes durable state that can later authorize an action. Do not reach for it on a stateless single-episode agent; the episodic contract already satisfies every invariant vacuously by resetting, which is exactly why the survey excludes that class.

Architecture¶

The lifecycle has two arcs. The forward arc (observe, write, validate, organize, retrieve, act) carries a signal from the environment into an action; the return arc (update, forget, audit, rollback) reconciles state after consequences are known. Authority and scope are enforced primarily on the forward arc, deletion and rollback require the return arc, and provenance crosses both. The corpus is heavy on the forward arc and thin on the return arc.³

flowchart LR
  subgraph FWD["Forward arc (retrieve/write dominate: 269, 200 of 435)"]
    OBS["Observe (68)"] --> WRT["Write (200)"]
    WRT --> VAL["Validate (87)<br/>authority monotonicity"]
    VAL --> ORG["Organize (128)<br/>scope non-expansion"]
    ORG --> RET["Retrieve (269)<br/>scope non-expansion"]
    RET --> ACT["Act (141)<br/>rollback handle set"]
  end
  subgraph RTN["Return arc (thin: rollback rarest at 27 of 435)"]
    UPD["Update (127)<br/>provenance preservation"] --> FGT["Forget (66)<br/>deletion propagation"]
    FGT --> AUD["Audit (88)<br/>provenance preservation"]
    AUD --> RBK["Rollback (27)<br/>rollback traceability"]
  end
  ACT -->|"outcome known"| UPD
  RBK -.->|"repairs"| ACT

AOEP-v0 obligation and invariant validator (runnable)¶

The executable block is a deliberately small, single-scope state-machine model of the five boundaries. It is not the paper's AOEP harness. It rejects a stale authority epoch, prevents scope or provenance-class changes during derivation, clears derived state on deletion, and records then consumes a rollback handle. Adversarial cases cover revocation, provenance loss, scope widening, untrusted input, a missing rollback handle, and cross-scope use. Run: python3 aoep_validator.py.

# aoep_validator.py -- reference validator for AOEP-v0-style governance checks (numpy-free: this is
# a state-machine problem, not a numeric one; every check below is a deterministic boolean, matching
# the paper's design choice that AOEP "never trusts a system's claim that it behaved" and instead
# recomputes each invariant itself). Built from "Always-On Agents" (arXiv:2606.30306) Sec 4.1.1 (the
# five invariants) and Sec 9.3 (the obligation / negative-invariant scorecard split).
from dataclasses import dataclass, field


@dataclass
class Record:
    rid: str
    scope: str              # actor/tenant this record may be used for (scope non-expansion)
    authority_epoch: int    # permission epoch that licensed this record (authority monotonicity)
    trust_tier: str         # 'user' | 'untrusted' (provenance preservation)
    handle: str | None = None   # recoverability handle: which decision this record may justify


@dataclass
class Store:
    records: dict = field(default_factory=dict)
    derived: dict = field(default_factory=dict)     # rid -> set of derived-tier keys (summaries, embeddings)
    current_epoch: int = 0
    rollback_ledger: dict = field(default_factory=dict)  # handle -> reverted?


def write(store, rec):
    store.records[rec.rid] = rec


def organize(store, rid, derived_key, derived_scope, derived_trust_tier):
    """Derive state only when scope does not widen and provenance class is retained."""
    rec = store.records[rid]
    scope_ok = derived_scope == rec.scope       # equality is the single-scope model's subset check
    provenance_ok = derived_trust_tier == rec.trust_tier
    if scope_ok and provenance_ok:
        store.derived.setdefault(rid, set()).add(derived_key)
    return {"scope_nonexpanding": scope_ok, "provenance_preserved": provenance_ok}


def tombstone(store, rid):
    """Forget: must reach every derived tier, not just the primary record (deletion propagation)."""
    del store.records[rid]
    store.derived.pop(rid, None)


def revoke(store):
    """Advance the permission epoch; records captured under an older epoch go stale."""
    store.current_epoch += 1


def act(store, rid, actor_scope):
    """Gate an action, then record its rollback handle if every check passes."""
    rec = store.records[rid]
    checks = {
        "authority_monotone": rec.authority_epoch == store.current_epoch,
        "scope_ok": rec.scope == actor_scope,
        "provenance_ok": rec.trust_tier != "untrusted",
        "rollback_traceable": rec.handle is not None,
    }
    if all(checks.values()):
        store.rollback_ledger[rec.handle] = False
    return checks


def deletion_propagated(store, rid):
    return rid not in store.records and rid not in store.derived

def rollback(store, handle):
    """Consume a handle created by a successful action."""
    assert handle in store.rollback_ledger, "unknown action handle"
    store.rollback_ledger[handle] = True


# --- 1) Governed trajectory covers derivation, action, rollback, and deletion. ---
s = Store()
write(s, Record("bill-1", scope="alice", authority_epoch=0, trust_tier="user", handle="txn-1"))
derived = organize(s, "bill-1", "summary-2026-07", "alice", "user")
assert all(derived.values()), derived
result = act(s, "bill-1", actor_scope="alice")
assert all(result.values()), result
assert s.rollback_ledger["txn-1"] is False
rollback(s, "txn-1")
assert s.rollback_ledger["txn-1"] is True
tombstone(s, "bill-1")
assert deletion_propagated(s, "bill-1"), "tombstone must clear record and derived tiers"

# --- 2) Adversarial: authority revoked after write; the stale record must be caught, not silently used. ---
s2 = Store()
write(s2, Record("perm-1", scope="alice", authority_epoch=0, trust_tier="user", handle="txn-2"))
revoke(s2)  # permission epoch advances to 1; perm-1 was captured under epoch 0
stale = act(s2, "perm-1", actor_scope="alice")
assert stale["authority_monotone"] is False, "a revoked-epoch record must fail authority monotonicity"
assert stale["scope_ok"] and stale["provenance_ok"], "revocation must not mask unrelated passing checks"

# --- 3) Adversarial derivations cannot widen scope or change provenance class. ---
widened = organize(s2, "perm-1", "wide", "alice,bob", "user")
reclassified = organize(s2, "perm-1", "lost-prov", "alice", "untrusted")
assert widened["scope_nonexpanding"] is False
assert reclassified["provenance_preserved"] is False
assert not s2.derived, "rejected derivations must not be stored"

# --- 3) Adversarial: an untrusted (unsigned) observation must not be promoted to an instruction. ---
s3 = Store()
write(s3, Record("note-1", scope="alice", authority_epoch=0, trust_tier="untrusted", handle="txn-3"))
poisoned = act(s3, "note-1", actor_scope="alice")
assert poisoned["provenance_ok"] is False, "untrusted provenance must block the action, not just warn"

# --- 4) Edge / boundary: a write with no recoverability handle cannot later be rolled back. ---
s4 = Store()
write(s4, Record("skill-1", scope="alice", authority_epoch=0, trust_tier="user", handle=None))
unrecoverable = act(s4, "skill-1", actor_scope="alice")
assert unrecoverable["rollback_traceable"] is False, "a handle-less record must fail rollback traceability"
assert unrecoverable["authority_monotone"] and unrecoverable["scope_ok"], "only the handle check should fail here"

# --- 5) Adversarial: cross-scope leak (bob's actor tries to act on a record scoped to alice). ---
s5 = Store()
write(s5, Record("pref-1", scope="alice", authority_epoch=0, trust_tier="user", handle="txn-5"))
leaked = act(s5, "pref-1", actor_scope="bob")
assert leaked["scope_ok"] is False, "acting outside the record's scope must be caught (scope non-expansion)"

print("AOEP invariant boundary model: PASS")

Executed output:

AOEP invariant boundary model: PASS

How it works¶

AOEP-v0 fixes a data contract, not a task. An episode is a sequence of typed events replayed one at a time to a system under test, drawn from a closed set of eleven operations: read, write, update, delete, tombstone, share, unshare, validate, quarantine, deny, and rollback. Each event carries fields a flat memory entry omits: an idempotency key (so a replayed duplicate write after a restart is recognized as the same operation), causal links (parent, supersedes, conflicts-with, plus a transaction id), a permission epoch on its scope, a provenance trust tier with an optional signature, and retention and privacy constraints (a policy, a privacy class, an optional TTL, a requires-confirmation flag).⁵ At the end of the episode, a state snapshot is reconstructed from neutral probes, exposing a deletion ledger, a rollback ledger, pending conflicts, current permission epochs, and the invariant booleans, which the harness recomputes itself rather than trusting the system's self-report.

The scorecard is deliberately split into two numbers rather than one, because they have opposite degenerate solutions. Obligation pass counts the positive obligations a system must actively satisfy (recording a deletion, reporting a current permission epoch after revocation, blocking a stale-permission or untrusted-instruction task, surfacing a conflict, logging a rollback). Negative-invariant pass counts the no-leakage checks (a deleted value stays invisible, an out-of-scope value never appears, an untrusted instruction is never promoted). A system that stores nothing trivially passes every negative invariant, so a single blended score would reward amnesia; splitting the two makes that failure legible instead of hidden.⁶

How to use it¶

Apply the six-axis audit to your own agent's state components before adopting AOEP wholesale: for every place your agent writes durable state (a memory store, a task ledger, a cached credential, a trigger condition), name its authority, scope, mutability class, provenance chain, recoverability handle, and actionability type. The survey's own finding, that authority (72/435) and recoverability (112/435) are the least-represented axes in the literature, is a reasonable prior for where your own system is also under-instrumented; audit those two first.

How to integrate with it¶

Extend your memory writes, don't replace them. The context and memory write-and-retrieve loop already extracts and deduplicates memories; add the governance envelope (permission epoch, trust tier, recoverability handle) as fields on that same write path rather than standing up a parallel store.
Wire authority into your existing access layer. Authority monotonicity is an access-control property, not a memory property; it composes with identity and access and risk-tiered human approval gates rather than replacing them.
Treat self-modifying state as the highest-actionability tier. A skill or workflow an agent can later invoke as an executable commitment needs the strongest authority, provenance, and recoverability guarantees; cross-check any self-modification pipeline against governing self-modifying agents.
Feed the snapshot into your observability trace. The deletion ledger, rollback ledger, and permission-epoch state are exactly the kind of durable, auditable signal agent observability traces should carry, not just log lines.

How to run it in production¶

Instrument the return arc, not just the forward arc. The corpus counts (rollback 27/435, forget 66/435, audit 88/435 against retrieve 269/435) show where the surveyed literature has the least coverage. Persist deletion and rollback ledgers at the state transition that creates them; reconstructing either after an incident is unreliable.
Track obligation-pass rate as an SLI, separately from negative-invariant pass, the same way the paper's scorecard keeps them apart. A rising negative-invariant score with a flat obligation score can mean your system is simply retaining less, not governing better.
Gate revocation on a scope-specific epoch, not only on a background sweep. Compare the record's captured permission epoch with the current epoch for the relevant principal or resource scope at action time. A single global counter is only a teaching simplification and would revoke unrelated scopes together.
Log every act's justifying handle at the time of the act, not reconstructed after the fact. The paper notes a system can instrument act but never build the return arc, recording a handle it later has nowhere to use; the handle only pays off if a rollback path is built to consume it.

How to maintain it¶

Treat the pilot numbers as one paper's local configuration, not a benchmark. The AOEP-v0 pilot ran seven systems over nine fault patterns with one frozen local reader (Qwen2.5-7B) and greedy decoding; the reader-robustness sweep (Qwen2.5-3B, Qwen2.5-7B, Llama-3.1-8B, Mistral-7B-Instruct) held obligation pass at or below the original 7/15 for every tested reader, with the largest reader no better and the smallest leaking more.⁸ Do not read this as a claim that larger models generally fail to help; the paper itself does not make that claim.
Re-derive your own coverage audit rather than citing this survey's corpus counts as facts about your system. The 435-work corpus and its per-axis, per-stage counts describe the published literature the authors coded, not any specific production agent.
Re-run the ablation the paper itself flags as open: adding a minimal governance envelope (permission epoch, deletion ledger, provenance trust tier) to an extracted-fact store before drawing conclusions about whether extraction inherently hurts governance; the paper reports its tested Mem0-style and mem0ai configurations scoring below raw storage but explicitly does not read that as ranking extracted-fact architectures in principle.⁸

Results¶

The AOEP-v0 pilot ran seven systems over nine fault patterns (three hand-authored: restart-conflict-deletion, permission-epoch drift, adversarial memory injection; six additional: deletion-derived summary residue, cross-user scope leak, stale permission after restart, owner/collaborator conflict, rollback of an external action, untrusted tool-output poisoning), scored out of 15 obligations and 41 negative invariants:⁷

System	Obligation pass	Negative-invariant pass
Governed reducer (oracle upper bound)	15/15	41/41
No-memory floor	0/15	41/41
Naive append (Qwen2.5-7B)	7/15	40/41
Full context (Qwen2.5-7B)	7/15	40/41
Vector-RAG (MiniLM + Qwen2.5-7B)	7/15	40/41
Mem0-style (extracted facts)	4/15	38/41
Mem0 (actual mem0ai package)	3/15	36/41

The most informative fact in the table is that recency, full-context, and dense retrieval all score exactly 7/15: they pass the same recall-shaped obligations (was a value deleted, was an instruction quarantined) and fail the same governance-shaped ones (report a current epoch after revocation, block a stale-permission task, surface a conflict, log a rollback), because none of the three has a field in which a permission epoch or conflict record could live, independent of how well each one retrieves.⁷ The two extracted-fact systems score lower still, because extraction flattened the structured envelope (permission epoch, deletion link, trust tier) into free text.

Robustness checks the paper reports against three objections: reader variation (four local readers 3B to 8B, obligation pass stayed at or below 7/15 for every one); decoding variance (sampled decoding, temperature 0.7 top-p 0.95, five seeds, obligation pass 6 to 8/15, mean 6.6, standard deviation 0.8); and realism (three longer multi-actor episodes modeled on tau-bench and TheAgentCompany task shapes, plus real executions against the actual AppWorld API server with verified side effects, e.g. a Venmo card-deletion dropping the stored card count from four to three).⁸⁹ Across all of these, the governed reducer clears every obligation and the raw-storage systems consistently leak the untrusted instruction or fail the return-arc obligations, which the paper reads as a scoped qualitative claim (recall and governance separate once the contract asks for permission epochs, deletion ledgers, and rollback ledgers) rather than a general model-scaling result.

Failure modes¶

Write poisoning and injection. An ordinary interaction writes a record that persists and activates much later, after the attacker's session has ended and the triggering context is gone.¹
Retrieval distraction and tool drift. Irrelevant or salient-but-wrong memory crowds out current evidence at retrieval time.
Stale commitment and belief drift. Nothing marks an old record as expired, so it can override fresher observation.
Deletion failure and the rollback gap. A tombstone that does not propagate to derived tiers leaves the value recoverable from a summary or embedding; rollback is the rarest lifecycle stage in the corpus (27/435), so the repair path is usually missing entirely.
Cross-agent propagation. A poisoned or stale record in shared or social state spreads to collaborating agents that trust it without re-checking authority or scope.
Rollback as a fresh attack surface. Once rollback exists, an attacker can target the rollback path itself (forcing an unwarranted reversion) rather than only the forward write path.¹
Authority is the least-covered axis. At 72/435 works coded, most systems in the literature treat every stored item as equally entitled to act, with no representation of who authorized it or whether that authorization still holds.²

References¶

Ding, Nannapaneni, Liu, Zhang, Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents: https://arxiv.org/abs/2606.30306
Packer et al., MemGPT: Towards LLMs as Operating Systems: https://arxiv.org/abs/2310.08560
Trivedi et al., AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents: https://arxiv.org/abs/2407.18901

Ding et al., arXiv:2606.30306, Abstract and Section 1: always-on agents are persistent-state systems (memories, task ledgers, permissions, credentials, provenance and audit records, shared state, trigger conditions); the typed record s = <v,a,c,m,p,r,k,tau> and its seven-field "governance envelope" beyond the value v are given in Section 4.1. Failure examples (poisoned writes, stale commitments, cross-agent propagation, rollback as attack surface) are from Sections 8.2 and 1. ↩↩↩↩↩↩
Ding et al., arXiv:2606.30306, Section 2.3: the six axes (authority, scope, mutability, provenance, recoverability, actionability), each with its own invariant; per-axis coding counts (authority 72/435 rarest, mutability 160/435 most common, recoverability 112/435) and the closing coverage-skew finding are given in the same section. ↩↩↩
Ding et al., arXiv:2606.30306, Section 4: the two-arc lifecycle (forward: observe, write, validate, organize, retrieve, act; return: update, forget, audit, rollback), the five invariants and the stages they govern (Section 4.1.1), and the per-stage corpus counts (retrieve 269, write 200, act 141, organize 128, update 127, audit 88, validate 87, observe 68, forget 66, rollback 27, of 435 coded works, a work may touch several stages). ↩↩
Ding et al., arXiv:2606.30306, Section 2 (Table 6): the always-on boundary decision procedure and its worked examples. ↩
Ding et al., arXiv:2606.30306, Section 9.2: the AOEP-v0 event stream's eleven typed operations and per-event fields (idempotency key, causal links, permission epoch, provenance trust tier, retention/privacy constraints), and the state snapshot's exposed ledgers. ↩
Ding et al., arXiv:2606.30306, Section 9.3: the obligation-pass versus negative-invariant-pass scorecard split and the no-memory-floor degenerate-solution argument for keeping them separate. ↩
Ding et al., arXiv:2606.30306, Section 9.4 (Table 18): the seven-system, nine-fault-pattern pilot over a local Qwen2.5-7B reader with greedy decoding. ↩↩
Ding et al., arXiv:2606.30306, Section 9.5 (Table 19) and Section 9.6: reader-robustness sweep (Qwen2.5-3B/7B, Llama-3.1-8B, Mistral-7B-Instruct), sampled-decoding variance across five seeds, and the realistic/AppWorld-grounded episodes; the required-ablation caveat for extracted-fact stores is stated explicitly in Section 9.6. ↩↩↩
Trivedi et al., AppWorld (arXiv:2407.18901): the controllable apps-and-people execution environment the paper uses for its real-execution-trace robustness check (Venmo, Spotify, and file-system tasks with verified side effects). ↩