Always-on agents turn memory into a governance problem (2026)

The important move in Always-On Agents is the framing: long-running LLM agents are not mainly a memory problem. They are persistent-state systems. Their future behavior can be shaped by retrievable memories, task ledgers, permissions, credentials, commitments, provenance records, shared state, trigger conditions, and external side effects. 1

That makes this survey a useful spotlight paper for the week. It was submitted to arXiv on 29 June 2026, covers cs.MA and cs.AI, and maps a 435-work corpus around one question: when agents keep acting after the current chat is over, what has to be governed, recovered, deleted, or rolled back? 1 The early community signal is also visible: a widely shared X post described it as a strong overview of always-on agents and called out durable state, six diagnostic axes, lifecycle, forgetting, audit, and rollback. 2

The paper is still a preprint, so treat it as a map and agenda rather than a settled benchmark. The authors say the corpus is a scoped map, not an exhaustive census. 1 That caveat matters. The paper's value is the taxonomy it gives system builders, not a final ranking of the whole agent literature.

The core turn: memory becomes state

A normal memory lens asks: what should the agent remember, and how should it retrieve it? This survey asks a harder operational question: what state can later authorize behavior?

That shift changes the risk model. A remembered preference may be harmless if it only changes wording. The same preference becomes more serious if it changes spending limits, sharing permissions, calendar actions, or which outside tool the agent can call. The paper's definition therefore includes memories but also ledgers, permissions, credentials, commitments, provenance and audit records, shared state, triggers, and externally committed effects. 1

A simpler way to read the paper: every durable item an agent carries forward should answer six questions.

Axis	Plain-English question for an agent system
Authority	Who or what allowed this state item to guide behavior? 1
Scope	Where is it allowed to apply: one task, one user, one team, one tool, or everywhere? 1
Mutability	Can it be edited, superseded, or frozen? 1
Provenance	Can the system explain where it came from? 1
Recoverability	Can the system restore a prior safe state? 1
Actionability	Can this state item trigger or shape future external action? 1

Those axes are the paper's most portable contribution. They turn memory design from a retrieval problem into something closer to database design, access control, audit logging, and incident recovery.

The taxonomy: three layers, not one memory bucket

The survey separates persistent state into three layers.

First is object state: the durable things the agent carries forward. The paper includes episodic traces, semantic facts, preferences or user models, procedural skills, workflow and task commitments, shared state, and trigger conditions. 1 This is the layer most current agent-memory products talk about.

Second is the governance envelope around each object. The envelope holds metadata or capability controls such as authority, scope, credentials, provenance, retention, deletion handles, rollback handles, trust, and temporal validity. 1 In practice, this is the layer that decides whether a memory can safely influence action.

Third is external commitments: messages sent, payments made, files changed, database rows written, tickets opened, or other side effects outside the agent's own store. The paper treats these as part of the state problem because an internal record may later refer to an external action that cannot simply be undone. 1

This three-layer model is the reason the survey is broader than a memory-system roundup. It covers what the agent knows, what authority travels with that knowledge, and what happens after the agent acts.

The lifecycle gap: agents are better at accumulating state than recovering from it

The paper's lifecycle has a forward arc and a return arc. The forward arc is observe, write, validate, organize, retrieve, and act. The return arc is update, forget, audit, and rollback. 1

The corpus coding shows a lopsided field. Retrieval and writing dominate; rollback is barely represented.

Lifecycle stage	Incidence in the 435-work coded corpus	What the number says
Retrieve	269 1	The center of gravity is still finding prior state.
Write	200 1	Many systems study how state enters memory.
Act	141 1	A sizable subset connects state to behavior.
Organize	128 1	Consolidation and structuring get moderate attention.
Update	127 1	Revision is studied, but propagation remains hard.
Audit	88 1	Accountability is present but not central.
Validate	87 1	The gate before state becomes durable is thin.
Observe	68 1	Input selection is less studied than storage and retrieval.
Forget	66 1	Deletion is not yet a first-class capability.
Rollback	27 1	Recovery is the clearest gap.

The asymmetry is the paper's strongest empirical signal. If a system can write and retrieve but cannot validate, audit, forget, or roll back, task performance can improve while operational risk quietly compounds.

Rollback is especially tricky because it can create new failures. If an agent restores an older state and retries tool calls, it may repeat irreversible actions unless the system records those external effects and replays the record instead of re-executing the action. The paper flags rollback as both a needed safety capability and a possible attack surface. 1

How AOEP-v0 changes evaluation

The paper proposes the Always-On Evaluation Protocol, AOEP-v0, to score state mutation and recovery obligations rather than answer quality alone. It includes an event-stream and snapshot schema, worked episodes, validator design, and a pilot that exposes missing governance fields in current memory wrappers. 1

That makes AOEP-v0 different from the usual memory benchmark.

Evaluation lens	Typical question	What gets missed
Memory QA over histories	Can the model recall or infer the right answer from prior interactions?	Whether the remembered item had authority, scope, provenance, or deletion rules.
Memory-guided action	Can memory improve the next task?	Whether the action should have been allowed under the state item's governance envelope.
State mutation and recovery	Did the system write, update, forget, audit, and roll back state correctly? 1	This is the gap AOEP-v0 is designed to test.

The protocol is early. It is best read as a contract shape: a way to say what a long-running agent owes the user when state changes. That is more useful than a leaderboard score at this stage.

The field timeline the survey implies

The paper's history runs in four rough phases.

Cognitive architecture and memory taxonomy. Agent memory starts with categories such as episodic traces, semantic facts, preferences, and procedural skills. 1
RAG, vector stores, graph memory, and long-context systems. The field learns to store, retrieve, consolidate, and inject prior information into model context. 1
LLM agents bind state to tools and workflows. Memory stops being only a recall aid. It starts shaping external action, permissions, task ledgers, and commitments. 1
Always-on systems need governance primitives. Validation, audit, forgetting, rollback, capability security, and recovery become part of the core design surface. 1

The timeline is not a clean replacement story. Retrieval does not go away. The point is that retrieval alone stops being enough once state can authorize future behavior.

What to take from it

For builders, the immediate checklist is concrete. Before adding another memory layer, ask what happens when the stored item is wrong, stale, over-scoped, poisoned, or no longer consented to.

The six-axis test is a good first pass:

Who authorized the state?
Where is it allowed to apply?
Who can edit or invalidate it?
Can its origin be traced?
Can the system recover a prior state?
Can it trigger outside action?

For researchers, the open space is even clearer. The field has many ways to write and retrieve agent memory. It has far fewer ways to prove that a long-running agent can delete, audit, and roll back state without causing fresh harm. That is why this survey is the right paper to spotlight: it turns agent memory into an engineering and governance problem that can be tested.

Always-on agents turn memory into a governance problem