Always-On Agents: What a New Survey Says About Persistent Memory and State
A 2026 arXiv survey frames persistent memory, state, and governance as what separates always-on LLM agents from single-session chatbots with memory bolted on.
A recent arXiv survey, "Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents" (arXiv:2606.30306), does something most agent papers don't: it names a category. Not "agents with memory" or "agents with long context," but agents that are expected to run continuously, across sessions, interruptions, and days, without resetting. The survey's framing is useful precisely because it ties together three threads that are usually discussed separately — persistent memory, resumable state, and governance of that persisted data — and argues they are one design problem, not three optional features.
This post walks through that framing and why it matters for anyone building agents that are meant to outlive a single conversation.
Single Session vs. Always-On: A Different Design Target
Most chatbot architectures still assume a bounded session: a user opens a thread, the agent responds using whatever is in the context window, and when the session ends, so does the agent's working knowledge. Memory, when it exists at all, is an add-on — a retrieval step bolted onto an otherwise stateless request-response loop.
The survey's core claim is that "always-on" agents break that assumption at the foundation. An agent that manages a codebase, monitors a pipeline, or maintains a long-running customer relationship doesn't get to forget between sessions. It needs to know what it decided last week, why it decided it, and whether that decision is still valid today. That's a different design target. It changes what has to be engineered from day one — decay, consolidation, staleness handling, and access governance — rather than retrofitted once the memory system is already in production and something has gone wrong.
Memory That Doesn't Reset
The first thread the survey pulls together is persistence itself: memory that accumulates indefinitely rather than resetting at session boundaries. This is the piece that's most visible right now — model providers have started shipping native memory tools, and the broader ecosystem has converged on retrieval-augmented memory as the practical mechanism for it, since no context window is large enough to hold an indefinitely growing history.
But persistence without curation just produces a growing pile of stale facts. That's why decay and consolidation mechanisms matter as much as storage. In Feather DB, for example, memory stickiness is computed as 1 + log(1 + recall_count), with a default half-life of 30 days — memories that get recalled repeatedly resist decay, while ones that never get touched fade out. That's a concrete instance of the general pattern the survey describes: persistent memory systems need a forgetting function, not just a write function.
The payoff for getting this right shows up in retrieval-quality benchmarks. On LongMemEval_S, Feather DB paired with GPT-4o scored 0.693, against a full-context GPT-4o baseline of 0.640 — evidence that structured, decaying, retrievable memory can outperform simply stuffing more history into the context window. That's the kind of result the survey's framing predicts: persistence has to be selective to be useful, not just large.
State Across Long-Running, Interruptible Sessions
The second thread is state management, and it's distinct from memory even though the two get conflated. Memory is what an agent remembers — facts, preferences, prior conclusions. State is where an agent left off — which step of a multi-step task it was on, what tools it had already called, what it was waiting for when the session was interrupted.
An always-on agent has to survive interruption. A process restart, a network drop, a user closing a laptop mid-task — none of these should force the agent back to step one. The survey treats resumability as a first-class requirement: agents need checkpointing and state serialization designed in, not a retry loop that silently discards progress. This matters more as agents take on longer-horizon tasks — multi-day research, ongoing monitoring, agent-to-agent handoffs — where "just start over" stops being a viable fallback.
Governance Is Not Optional Once State Persists
The third thread, and the one the survey spends real effort on, is governance — and it's the thread most single-session chatbot architectures never had to think about. If memory resets every session, there's nothing to audit, nothing to poison, nothing to leak across users. Once memory and state persist indefinitely, all three become real risks.
OWASP has already named memory poisoning as a distinct risk category for LLM systems — the injection of false or manipulated information into an agent's persistent store, designed to corrupt future decisions rather than the current response. That's a fundamentally different attack surface than prompt injection against a single turn, because the payload doesn't have to work immediately. It just has to sit in memory until it's recalled.
The survey also points to governance gaps around stateful sessions in protocols like MCP (Model Context Protocol) — specifically, the lack of settled conventions for who can read a given piece of persisted state, who can write to it, and how that access gets audited over time. For a single-session tool call, access control is scoped to the conversation. For an always-on agent with a memory store that outlives any one session, access control has to be a standing policy, not a per-request check.
Put together, the survey's governance argument is: decay, consolidation, and access control aren't performance optimizations layered on top of a working memory system. They're the mechanism by which persistent state stays trustworthy at all.
Why This Changes the Build Order
The practical upshot of treating memory, state, and governance as one problem is that it reorders what gets built first. In a single-session, memory-optional design, you can ship the chat loop, and add retrieval later if users ask for continuity. In an always-on design, per the survey's framing, decay and consolidation logic, staleness handling, and read/write governance need to exist before the agent's memory store has anything valuable in it — because by the time it does, retrofitting access control onto an already-populated store is a much harder problem than designing it in from the start.
It's worth being precise about what this survey is and isn't. It's a recent academic synthesis of a fast-moving area, not an established standard or an industry consensus position. The individual pieces it ties together — native memory tools, decay mechanisms, OWASP's memory poisoning category, MCP's governance gaps — are each independently real and citable. The survey's contribution is naming the pattern across them: that these aren't separate trends, but symptoms of agents shifting from single-session tools to always-on systems that need memory, state, and governance engineered together.
Frequently Asked Questions
What makes an agent "always-on" rather than just "has memory"?
Per the survey's framing, it's the combination of three things: memory that persists indefinitely rather than resetting per session, state that survives interruption and resumes cleanly, and governance over who can read, write, and audit that persisted data. An agent with memory but no resumable state, or memory with no access control, doesn't fully meet the bar.
Is persistent memory the same thing as a long context window?
No. A long context window extends how much can fit into a single request; it still resets between sessions unless paired with an external store. Persistent memory means information survives across sessions and gets selectively retrieved, decayed, or consolidated over time — a different mechanism than simply enlarging the window.
What is memory poisoning, and why is it different from prompt injection?
OWASP categorizes memory poisoning as the injection of false or manipulated data into an agent's persistent memory store, intended to influence decisions in future sessions rather than the current response. It's distinct from single-turn prompt injection because the corrupted data can sit dormant until it's recalled, making it harder to trace back to its origin.
Does building an always-on agent require a hosted memory service?
Not necessarily. The survey's framing is about design requirements — persistence, resumable state, governance — not about deployment model. Those requirements can be met with a self-hosted, embedded store as easily as a managed one; what matters is that decay, consolidation, and access control are designed in rather than left out.
If you're weighing how to add persistent, decaying, governable memory to an agent, Feather Core is free and MIT-licensed at pip install feather-db — worth a look before you build that layer yourself.