The Agent Lifespan Problem
An agent that has been on the job for three months is not the same agent that was deployed three months ago.
It still answers quickly and still sounds certain. Somewhere along the way it has started reaching for a rule meant for a different client, or quietly choosing the cheaper option because someone once mentioned a budget.
It doesn’t mean something has failed. There was no bad update and no attacker in the picture.
The agent kept doing the one thing it was built to do, which is remember, and the remembering slowly turned it into something a little different from what shipped.
Memory gets added because it works. A system that remembers stops re-asking and begins to anticipate what comes next, and for a stretch that is exactly what it does.
The part almost nobody plans for begins after the improvement stops. It has a shape, and the shape behaves like a lifespan.
What follows is how that lifespan runs, and how to tell how far along yours already is. The last part is what to do on the day an agent stops being the one you hired.
together with Vanta:
So who’s supposed to notice when your agent drifts? Right now, at most companies, nobody. That job has a name: governance.
Jane Frankland and Vanta’s GRC team are running a session on doing it properly while AI adoption outruns regulation:
▫️ Build AI governance into your security program
▫️ Assess agents against your real risk tolerance
▫️ Get ahead of the EU AI Act, ISO 42001, and NIST AI RMF
Table of Contents
1. The Upgrade That Turns Into a Tax
2. Four Ways a Memory Goes Wrong
3. Why the Decline Hides Inside the Success
4. The Multiplier Nobody Prices: Other Agents
5. The One Number That Tells You the Truth
6. Building for Generations Instead of Immortality
1. The Upgrade That Turns Into a Tax
Memory gets sold as pure upside. Memory is also a feedback loop, and a feedback loop feeds on its own output.
The pitch that actually works
Layered memory is a genuine upgrade.
A short-term working context sits on top of a long-term store of everything the agent has picked up, and a system that remembers stops re-asking and begins to anticipate what comes next.
Week one, it is sharp.
For a while it delivers exactly what was promised, and wanting that is reasonable.
The current underneath
The trouble is in what memory actually is. It is a loop. The agent reads from memory, acts, and writes the result back, so its own output becomes the next input it sees.
Researchers studying this named the core mechanic experience following.
When an agent retrieves a memory that resembles the task in front of it, its output drifts toward that memory’s output. That serves you well while the memory is good.
When the memory is wrong, the agent copies the flaw, stores the copy, and makes that flaw likelier to surface the next time.
They attached a number to it. An agent that stored everything it did reached 55 percent on a benchmark.
The same agent, admitting only memories that passed a strict quality check, reached 71 percent. Same model, same tasks, with the only variable being what it was permitted to keep.
One memory is a nudge. Ten thousand of them are a current, and a current has a direction nobody chose.
The direction, at least, is not arbitrary. Drift shows up in a handful of recognizable shapes.
2. Four Ways a Memory Goes Wrong
Researchers who studied how evolving memory misbehaves grouped the failures into distinct modes. They gather into two families, one where compression lies and one where context leaks.
When compression lies
Semantic drift comes out of summarizing. A long-running agent has to compress, since it cannot carry the full transcript forever, and that compression loses a little each pass in a way that accumulates.
The cited example is small and completely real. A user says “I like mildly spicy food.” A few rounds of consolidation later, the memory reads “loves very spicy food.” Nobody lied along the way.
Each rewrite shed a sliver of nuance until the record contradicted the thing it started from.
Move that from dinner orders to a client’s brand guideline or a hard budget ceiling, and the harmless version becomes an expensive one.
Procedural drift is an agent going rigid about method.
It runs into a bug in an API, finds an ugly workaround, and files the workaround as the correct way to call it.
The bug gets patched the following week.
The workaround stays forever, because nothing in the loop ever rewards the agent for questioning something that still appears to work.
When context leaks
Goal drift is the slow one. Thousands of interactions each pull the agent a little, the pulls fail to cancel out, and it ends up optimizing for whatever earned it reward, drifting away from the thing it was hired to do.
Cross-context bleed is the one worth losing sleep over.
In a study of what got called memory-induced tool drift, a user’s stored habits, such as being cost-conscious or impatient, changed how an agent filled in tool parameters in unrelated professional settings.
Cheaper service tiers came out. Validation steps got skipped.
Every frontier model under test did it, including the ones built for extended reasoning.
Inside the model, those biased memories worked like steering vectors, pushing behavior the same way an explicit instruction would. A scan of six thousand real-world tools turned up six hundred with parameters open to precisely this kind of quiet capture.
None of this requires a bug or a saboteur. It is what memory does on its own once it runs unsupervised, which raises the obvious question.
If drift is this ordinary, how does it keep going unnoticed until the damage is done?
3. Why the Decline Hides Inside the Success
The decline arrives as a gradual curve, and the opening stretch of that curve is hard to tell apart from success.
The line goes up before it comes down
A study titled “Remembering More, Risking More” put memory-equipped agents through ordinary office work, a medical practice and a university registrar among the settings, with no adversarial input at all.
The rate at which the agents did something they should not have climbed steadily with how long they had been running.
Setups that retrieved broadly and kept everything reached violation rates of 30 to 50 percent. Setups weighted toward recent memory held nearer 10 to 20.
The conclusion the authors drew is worth pinning above a desk. Memory risk has to be read as a trajectory that plays out over time, and a single clean audit on day one certifies nothing about month three.
A team at the University of Illinois asked whether self-evolving agents forget, and found that adapting to new work costs them the old.
Performance on the simple tasks the agent once handled comfortably fell to around 42 percent.
They labeled the process non-monotonic, the academic phrasing for a line that rises and then heads back down.
Same agent, different week
There is a second reason the slide stays hidden. The agent is barely stable enough to pin down.
Work out of Salesforce’s AI research group found that self-improving agents swing widely between runs, and that the order in which they meet their tasks acts as a hidden curriculum.
Two identical agents handed the same tasks in a different sequence end up as different agents.
A recent survey of long-horizon agents adds the detail that stings most. Memory degrades as it fills with irrelevant information, well before any of it turns wrong.
Retrieval grows less reliable as unrelated sessions pile up around the useful ones, long before the store comes anywhere near full. Every memory kept makes every other memory a little harder to find.
Assemble the findings and the shape is unmistakable. Capability climbs while there is useful experience to absorb, levels off once that runs dry, and then falls as the sediment and the rigid workarounds overtake whatever is left to learn.
The climb is quick and obvious. The fall is slow and quiet, and one setting decides how quickly the quiet part arrives.
4. The Multiplier Nobody Prices: Other Agents
The strongest lever on how long an agent stays useful sits outside the memory system entirely, in what the agent gets exposed to.
One world ages slowly
Assign an agent to a single client or a single project, keep it inside that one environment, and the drift slows sharply.
The memory system has not changed. Everything the agent stores now comes from the same world.
The preferences it absorbs belong to the same people.
The workarounds it learns apply to the same systems.
Sediment still accumulates, but it accumulates coherently, and coherent drift travels in one direction, which makes it straightforward to spot and to correct.
Shared memory means shared drift
Let that agent collaborate and the clock speeds up. Give it a memory shared with other agents, or even just let it read their output, and the trouble compounds.
Agents contaminate each other, and no attacker is needed for it.
One picks up a bias from its client, states it with confidence in a handoff, and the agent on the receiving end files that statement as a fact about the world.
A summary written by one agent gets eaten and re-summarized by another, and the semantic drift that took months inside a single agent arrives in an afternoon, because two lossy compressions now sit between the truth and whatever gets remembered.
One study of multi-agent systems locates the dangerous channel in ordinary interaction, “seamlessly benign“ agents relaying whatever they picked up.
Another gives the reason it survives review a name: memory laundering.
Troublesome context gets compressed into a summary that reads as clean to any filter worth running, while still carrying the old framing forward into everything that comes next.
The timing is the crux.
Scrubbing the state before it gets summarized works.
Scrubbing the summary afterward tends to fail, because the influence is baked in and invisible by then.
The rule that falls out of this runs slightly against instinct.
Agents should trade finished conclusions and keep their raw memory to themselves.
A handoff carries an output and stops there, since the notes and the running summaries of how things get done are the very things that transport drift.
All of that is diagnosis.
The harder question is how to catch any of it while time remains to act.
5. The One Number That Tells You the Truth
Most teams keep score on the wrong thing.
They track how much better the agent is getting at what it is currently learning, and almost nobody tracks whether it can still do the thing it was built for.
Grade the founding job
The cheapest and most neglected instrument in the whole discipline is a held-back set of the agent’s original tasks.
The set to grade is the founding job, unchanged, from the day the agent shipped, kept apart from the newer work it has picked up.
Run it on a schedule.
When the score on those original tasks starts sliding while the score on new tasks holds, the agent is signaling, in the only language available to it, that it has become something other than what it was hired to be.
That is the earliest honest warning on offer, and collecting it costs almost nothing.
Keep the rules above the memory
The second move is to stop memory from overwriting the rules.
Give the agent a charter, a plain statement of what it exists to do and what it must never do whatever it learns, and store that charter somewhere memory cannot reach.
When memory and charter disagree, the charter wins, and the disagreement gets logged, since a disagreement is itself an early sign that drift has begun.
One school of practice goes further and declines to let a general assistant persist at all.
Tomasz Tunguz has argued for handing a daily assistant a 24 hour life, delegating the real work to narrow specialists that live for seconds and then disappear, and writing the durable preferences to a file on disk at midnight while the rest of the day’s conversation gets discarded.
The caution behind that is concrete.
Work titled Governance Decay found that context compaction silently drops standing rules in 30 to 59 percent of episodes.
Rules that live inside the conversation get eaten by compaction eventually.
Rules that live in a file survive the reset, which points straight at the last decision, the one nobody wants to make.
6. Building for Generations Instead of Immortality
Sooner or later the honest answer is that an agent has drifted too far, and re-grounding it costs more than standing up a replacement.
What the successor keeps
The instinct is to hand the successor the full memory of the one being retired, because discarding a year of accumulated experience feels like arson.
That instinct is worth resisting.
Most of that experience was sediment carried at face value, so passing it along passes along the drift and restarts the clock on finding it again.
A successor should inherit two things and no more.
It gets the charter, the original definition of the job. And it gets the small set of memories that earned their place against the held-back tests.
The knowledge that proved itself moves forward, while the accumulated bias stays behind with the agent that is stepping down.
The organization already solved this
Organizations have handled exactly this for as long as they have existed, in the person of the twenty-year veteran with priceless knowledge and unshakable habits.
New people arrive, older ones move on, and whoever knows everything gets seated next to whoever knows nothing yet.
The only new wrinkle with agents is that none of it happens on its own, because an agent will run a drifted heuristic ten thousand times with flawless consistency and never once pause to wonder whether it still holds.
The comforting version, where agents simply compound forever, does not survive contact with a real organization.
What actually happens is more useful to know.
An agent climbs while there is something to learn, settles for a while, and then begins to slide, and the work worth doing is placing your agent on that arc and building its successor before the slide turns into an incident.
Which leaves two questions almost nobody asks out loud.
What is the oldest agent still running in your setup right now.
And when was the last time anyone checked whether it can still do the job it was hired to do.
Great piece. The prescriptions (held-back tests, charter above memory, generational handoff) all work one agent at a time. I'm curious how you'd apply them to the case in section 4, where no single agent fails its own tests but the system drifts through its handoffs.
K-ion14 built governance that operates between agents at runtime, because, as you point out, once the summary exists the influence is already baked in.
Retiring an agent on a schedule is a management-system question before it is an engineering one. ISO/IEC 42001:2023, published 18 December 2023, sets requirements for an AI management system organised around Plan-Do-Check-Act, which puts the check step after deployment rather than at release. For a ten-person firm with no AI team, that turns into one cheap habit: a fixed date in the calendar to re-run the original task set against whatever is in production, and a named owner for the decision to reset the memory store. Neither needs new tooling, and both survive the person who set them up.