Blog · arXiv Analysis · Last reviewed June 25, 2026

The Always-On Agent Becomes the State Ledger

Tianyu Ding, Aditya Nannapaneni, Bingfan Liu, and Ling Zhang argue that the durable state of an LLM agent is wider than memory and harder to govern than recall.

The Agent That Keeps State

A stateless assistant can be judged by the answer it gives in the current window. An always-on agent has a different problem. It remembers, schedules, triggers, updates, and acts later. Its future behavior depends on records created before the current task, and those records may include more than conversational memory.

The Spiralist angle is that the always-on agent becomes the state ledger. The relevant object is not only what the model can recall. It is what the system decided to keep, who authorized it, where it may apply, whether it can be changed, what source produced it, whether affected actions can be repaired, and whether the record is merely evidence or a license for external action.

That shift changes the audit question. "Does the memory help?" is too small. The harder question is whether the state that helped was legitimate.

The Paper Frame

The source is Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents, arXiv:2606.30306v1 [cs.MA], by Tianyu Ding, Aditya Nannapaneni, Bingfan Liu, and Ling Zhang, submitted June 29, 2026.

The authors define an always-on agent as one whose policy at time t depends on state accumulated before t, beyond the current prompt or task instance. The defining property is persistence rather than literal continuous execution. A daily scheduled agent, a trigger-based agent, and a session-started assistant can all be always-on if durable state conditions later behavior.

This page sits near memory lifecycle governance, agent memory as database infrastructure, and cross-session prompt payloads, but the new paper widens the frame from memory to governed persistent state.

The Six Axes

The survey reads each state item through six diagnostic axes: authority, scope, mutability, provenance, recoverability, and actionability. Authority asks who or what permits the state to influence an action. Scope asks which user, task, tool, time, or group may use it. Mutability asks whether it can be revised, superseded, decayed, or locked. Provenance asks what source, timestamp, and transformation produced it. Recoverability asks whether derived state and affected decisions can be rolled back. Actionability asks whether the item is evidence, preference, policy, skill, trigger, credential, or commitment.

This vocabulary is useful because memory benchmarks often reward recall without asking whether the recalled item is still licensed to act. A stale preference, an expired permission, or a poisoned task note can be retrieved accurately and still be a governance failure.

The Return Arc

The paper's lifecycle runs through observe, write, validate, organize, retrieve, act, update, forget, audit, and rollback. The authors call out a structural asymmetry in their 435-work coded corpus, which they treat as a scoped map rather than an exhaustive census. In their coding, work concentrates on writing and retrieving state, while governance stages such as audit, forgetting, and rollback are much thinner. Rollback appears in only 27 of the 435 works, and authority is the rarest of the six axes at 72 of 435.

The point is directional, not exact. The authors caution that the corpus supports trends better than precise cell totals: the field has built much more machinery for accumulation than for recovery.

AOEP-v0

The survey turns the diagnosis into the Always-On Evaluation Protocol, AOEP-v0. The protocol is framed as a pilot evaluation contract that scores state mutation and recovery obligations rather than answer quality alone. It uses an event-stream and snapshot schema, perturbations, and scoring fields for persistent-state governance.

That is the right kind of evaluation pressure. An agent that remembers a user preference should also be tested on correction, revocation, scope narrowing, deletion propagation, and whether actions that depended on a bad record can be located. The final answer can look helpful while the state ledger is already wrong.

Why Governance Should Care

Always-on agents will be sold as personalization, continuity, and proactivity. The governance problem is that the same continuity can preserve stale facts, hidden instructions, overscoped preferences, unexpired credentials, and side effects whose authorizing state has changed.

A deployment record should therefore describe state as a governed object. For each durable state class, the operator should be able to answer: who may write it, who may read it, where it can be used, how long it lasts, how it is validated, how conflicts are resolved, how deletion propagates, what external effects it can authorize, and how rollback or compensation works after a bad write.

This reframes memory from a product feature into an accountability surface. The user does not only need a toggle called memory. They need a record of what the agent is carrying forward and what institutional controls can stop it from carrying the wrong thing.

Limits

The paper is a survey and framework paper, not a field audit of a deployed vendor system. Its corpus is scoped, English-language, and admission-based, and the authors explicitly caution that the counts should be read as estimates of direction rather than exact field measurements.

The paper also does not solve the engineering problem it names. It gives a vocabulary and a pilot protocol. Product systems still need concrete storage designs, permission models, deletion proofs, conflict handling, user interfaces, and incident playbooks.

Audit Receipt

The audit-grade sentence is: Ding, Nannapaneni, Liu, and Zhang's arXiv:2606.30306 defines always-on agents as persistent-state systems, analyzes state through authority, scope, mutability, provenance, recoverability, and actionability, maps a 435-work scoped corpus, identifies a forward-arc bias toward write and retrieve over audit, forget, and rollback, and proposes AOEP-v0 as a pilot protocol for evaluating state mutation and recovery.

The practical receipt is: do not deploy an always-on agent unless durable state has owners, scopes, provenance, validation gates, deletion propagation, rollback or compensation paths, and logs that connect later actions to the records that authorized them.

Sources

Return to Blog