The reliability question for deployed agents is not just whether they work on the first task. It is how long they keep working after their memory starts changing.

Source note: Jianing Zhu, Yeonju Ro, John T. Robertson, Kevin Wang, Junbo Li, Haris Vikalo, Aditya Akella, Zhangyang Wang. “Your Agents Are Aging Too: Agent Lifespan Engineering for Deployed Systems.” arXiv:2605.26302, 2026-05-25. https://arxiv.org/abs/2605.26302

Why This Paper Matters

Most agent benchmarks still treat agents as freshly initialized systems. The model receives a task, maybe calls tools, produces an answer, and gets scored.

That is not how deployed agents behave.

A real personal assistant, coding agent, research assistant, or enterprise workflow agent accumulates state. It summarizes old conversations, retrieves from a growing memory store, updates facts, rewrites workspace files, survives prompt changes, and occasionally goes through maintenance events like memory compaction or migration.

The model weights may be frozen, but the agent’s effective state is not. Over time, the same agent can become less reliable without obviously breaking. It may still sound fluent. It may still follow the right conversational pattern. But a medication dose can become “a daily medication,” two similar contacts can blur together, a canceled subscription can remain active, or a recurring schedule can vanish after a memory cleanup.

This paper gives that problem a useful name: agent aging. More importantly, it argues that aging is not one failure mode. It is a family of failures that require different repairs.

The Idea in Plain English

The paper’s core point is that deployed agents need lifespan engineering.

Day-one evaluation asks, “Can the agent solve this task now?” Lifespan evaluation asks, “What happens after the agent has lived with changing state for weeks, months, or hundreds of sessions?”

The authors introduce AgingBench, a benchmark suite designed to stress long-lived agents. It does not only measure whether the agent’s answer is wrong. It tries to identify what kind of aging happened and which part of the memory pipeline should be repaired.

The paper organizes agent aging into four mechanisms.

Compression aging happens when the agent writes memory too lossy. A future-relevant detail is dropped during summarization.

Interference aging happens when too many similar memories accumulate. The relevant fact may still exist, but retrieval pulls the wrong one.

Revision aging happens when facts change and the agent fails to update the active state. This is especially painful for derived state, such as a budget that depends on a sequence of additions and deductions.

Maintenance aging happens when a lifecycle event, such as memory flushing, recompaction, migration, or a prompt update, creates a sudden regression.

The practical value is the split. “The agent forgot” is not a diagnosis. It might need a better write policy, better retrieval, a typed state representation, more deliberate re-reading, or a regression check after maintenance.

What the Researchers Tested

The paper introduces AgingBench as a longitudinal benchmark for agent lifespan engineering.

It evaluates agents across 7 scenarios, 14 models, multiple memory policies, and both runner-controlled and autonomous agents. The authors report more than roughly 400 runs spanning 8 to 200 sessions.

The scenarios are designed around common long-running agent settings: a research literature agent, a lifestyle assistant, a project knowledge base, a software engineering agent, autonomous self-management, a naturalistic multi-domain agent, and a self-planning agent for closed-source production-style agents.

The benchmark uses a temporal dependency graph. In plain terms, the system knows which facts were introduced in which sessions, which facts supersede earlier facts, which facts are confusable, which probes depend on multiple earlier sessions, and when lifecycle events happen.

That structure lets the benchmark measure more than a final score. It can ask whether the current value was used instead of a stale value, whether the right entity was retrieved among similar entities, whether a derived budget still reflects the full update history, and whether performance changed immediately after a maintenance event.

The paper also introduces counterfactual diagnostic probes.

In P1, the agent uses its normal write, retrieval, and utilization loop. In P2, retrieval is replaced with an oracle retriever, but the agent’s own written memory is left intact. In P3, both write and retrieval are replaced with gold context, so the model is handed the facts needed for the answer.

The gaps between those conditions create a repair-oriented profile. If oracle retrieval helps, retrieval was likely part of the problem. If gold context helps beyond oracle retrieval, the agent may have failed to write enough detail. If the model still fails with gold context, the issue sits in utilization: it had the needed information but did not use it correctly.

What They Found

The main result is not that every agent gets worse in exactly the same way. The result is that aging is multi-dimensional.

No Single Model Dominated Every Aging Mode

Across the reported matrix, a model or memory policy that looked good under one mechanism often looked ordinary or weak under another.

That matters because buyers and builders often compress agent quality into a single memory score. The paper argues that this hides deployment-relevant differences. A support agent, a coding agent, and a personal assistant may age through different mechanisms, so the right model or harness depends on the operational pressure.

Behavioral Tests Can Stay Clean While Facts Decay

One of the strongest findings is that visible behavior can look fine while factual precision drops.

In the lifestyle-assistant scenario, explicit constraint violations stayed near zero while constraint precision fell. The agent continued to behave like it understood the user’s budget and preferences, but the underlying values had degraded.

This is the dangerous version of agent aging. The system does not fail loudly. It gives plausible answers with the wrong state.

Revision Aging Was Not Just a Capacity Problem

The paper finds that revision failures do not consistently disappear with larger models or different memory policies.

For tasks like budget tracking, the agent has to maintain derived state across a sequence of updates. Missing one delta can poison every later answer. The authors argue that this looks representational: the system needs explicit state maintenance or periodic recomputation, not merely a bigger memory window.

This is a useful warning for product teams. If an agent tracks mutable business state, summaries are the wrong primitive for some values. The agent may need typed records, ledgers, invariants, and recomputation paths.

Autonomous Agents Still Had a Write-Read Gap

The paper also tests autonomous CLI-style agents with self-managed workspace memory.

The interesting pattern is that workspace fidelity can be higher than downstream recall. In other words, the agent may have written useful files, but still fail to retrieve enough of them before answering.

That moves the repair target. Better storage is not enough if the planning loop does not decide to look in the right places, re-read enough context, or spend enough retrieval budget before producing an answer.

Maintenance Events Can Cause Abrupt Regressions

The maintenance results reinforce a simple operational lesson: an agent can regress because of routine care.

Memory flushing, recompaction, migration, prompt updates, and other lifecycle changes are not neutral housekeeping. They can change the effective state of the deployed agent. The paper treats these as measurable shock events, comparing pre-event and post-event performance windows.

That is exactly the kind of failure production teams need to catch with regression tests, not anecdotes.

Why It Happens

A deployed agent is not just a model. It is a model inside a harness.

That harness writes memory, stores it, retrieves from it, decides how much to read, uses tools, maintains workspace state, and goes through lifecycle changes. Reliability depends on the whole loop.

A single wrong answer can come from several places. The relevant fact may never have been written. It may have been written but not retrieved. It may have been retrieved but not used. Or it may have been erased or distorted during maintenance.

The paper’s counterfactual probes are useful because they turn a vague symptom into a repair direction. The point is not perfect causality. The point is operational triage: where should engineering effort go first?

That framing is more realistic than treating memory as a single capability. Long-lived agents are stateful systems. Stateful systems need instrumentation, regression testing, migration discipline, and repair playbooks.

What This Means for Builders

Builders should stop treating memory as a feature and start treating it as a lifecycle surface.

If an agent writes summaries, test whether exact values survive. If it retrieves from long-term memory, test confusable entities. If it updates state, test stale facts and derived values. If it goes through compaction or migration, run pre/post regression probes.

The paper also suggests a design rule: different facts deserve different storage forms.

Narrative context can often live in summaries. Exact values, current status, permissions, budget balances, account state, and user constraints probably should not. They need structured records, versioning, or recomputation from an event log.

For agent loops, retrieval budget deserves explicit control. An agent that has written useful files but fails to re-read them is not a memory-storage failure. It is a planning and utilization failure.

What This Means for Buyers and Operators

For buyers, this paper is a good antidote to day-one demos.

Ask vendors how their agents behave after 50 sessions, not only on a fresh benchmark. Ask whether they test stale facts, confusable entities, derived state, and memory maintenance events. Ask what happens after a prompt migration, memory compaction, model upgrade, or workspace cleanup.

For operators, the useful question is not “does the agent have memory?” It is “which memory failure modes are being monitored?”

An agent used for low-stakes drafting may tolerate lossy summaries. An agent used for customer records, project commitments, compliance workflows, or personal scheduling needs stronger state discipline. The more the agent’s output depends on accumulated state, the more it needs lifespan testing.

The paper also points to a procurement trap: a stronger base model may not fix the actual aging mechanism. If the problem is write-time omission, retrieval confusion, or state revision, the answer may be harness design rather than model upgrade.

What to Watch Next

The field should watch whether lifespan benchmarks become part of agent evaluation.

Model cards are not enough for agents. Useful agent evaluations should report the memory policy, retrieval policy, maintenance process, state representation, and recovery behavior.

Builders should watch typed memory and event-sourced state. The paper’s revision-aging results make a strong case that some agent memory should look less like a chat summary and more like a system of record.

Operators should watch for regression suites around maintenance. Any serious long-lived agent should have tests that run before and after compaction, migration, prompt changes, or model swaps.

Researchers should watch the gap between synthetic aging pressure and messy production use. AgingBench creates controlled pressure so the mechanisms can be isolated. The next step is connecting those mechanisms to real deployment traces.

Limitations and Caveats

AgingBench is a benchmark, not production reality. The scenarios are programmatically generated so the authors can isolate mechanisms, vary pressure, and compute gold-grounded metrics. That control is useful, but it does not capture the full mess of real users, organizations, tools, and incentives.

The attribution profiles are repair-oriented signatures, not perfect causal proof. If P2 or P3 improves accuracy, that tells builders where a repair is likely to help. It does not fully explain every internal reason a model or harness failed.

The paper also studies a selected set of models, frameworks, and memory policies. Different production harnesses may age differently, especially systems with stronger structured memory, explicit event logs, or human review loops.

Finally, aging is only one reliability axis. Security, tool authorization, hallucination, privacy, cost, latency, and human handoff still matter. Lifespan engineering adds an important missing lens; it does not replace the rest of the reliability stack.

Source

Zhu, J., Ro, Y., Robertson, J. T., Wang, K., Li, J., Vikalo, H., Akella, A., & Wang, Z. (2026). Your Agents Are Aging Too: Agent Lifespan Engineering for Deployed Systems. arXiv preprint arXiv:2605.26302. Available at: https://arxiv.org/abs/2605.26302