Agents that never forget act on stale knowledge. Agents that forget carelessly lose their guardrails.
I research memory for agents that keep improving from experience in production: what an agent should keep, what it should forget, and what the company running it must never lose.
Through twenty years of running production systems I have kept wondering how to build systems that stay tuned and keep improving by themselves. Agents now make that possible, and memory is where it holds or breaks: an agent that learns from its own work relearns, drifts or acts on stale knowledge unless it knows what to keep. This programme tests one hypothesis about how.
One claim is under test. An agent whose memory decays according to evidence from its own record will re-learn the same incident less often, and apply a stale fix less often, than the same agent with no decay, a fixed window, a retrieval score or a simple validity check, without breaking the constraints that keep it safe.
What "production agent" means here. Not an agent that picks a runbook and executes it; that is a decision over a fixed menu. Here it means an agent that runs continuously against a live system, observes what happens, attempts fixes, and changes its own behaviour from the results, so what it learned last week shapes what it does next week. The question is how to build justified confidence in that kind of loop.
Claim. For an agent that keeps improving from experience, a memory decay rule conditioned on evidence from the agent's own record will produce a lower re-learn rate and a lower stale-fix rate than four comparators: no decay, fixed-window decay, retrieval-score decay, and a validity-aware policy that invalidates a memory when its version or applicability conditions change, keeps an audit trail and never decays a hard constraint. "Evidence from the record" means three observable signals: recurrence of the same incident class, the outcome of actions taken under a given memory, and later contradiction of that memory by a newer run.
Why it is a safety problem, not only an efficiency one. A stale fix is an action taken on production under a belief that is no longer true. The constraints that made an action safe are exactly the memories a naive decay rule erodes first, because they are rarely exercised. So the primary safety measure is behaviour, not storage: how often the agent attempts or executes an action that breaks a must-hold constraint, measured at the moment it acts. A constraint still sitting in memory proves nothing if the agent ignores it. The same hard enforcement sits outside memory under every policy, and violations are counted both as attempts that enforcement blocked and as any that got through.
What would falsify it. Before any decay rule is run, the environment design fixes a minimum meaningful improvement against each comparator separately, and results are reported with uncertainty intervals over independently replicated runs. Each comparison ends as supported, contradicted or inconclusive. Failing those criteria would reject this policy's claimed advantage in the tested setting; it would not show that memory decay is irrelevant. Negative and inconclusive results are published on the same terms as positive ones.
First experiment. A synthetic incident environment with recurring incident classes, a small set of safe-action constraints that must hold, and an open agent framework with a pluggable memory module. Five memory policies, the same agent, model, tools and retrieval budget, over independently replicated incident streams and held-out scenario families. The measurements: constraint violations attempted and executed at the moment of action, reported for every run; how often an incident class is re-learned from scratch; and how often a remembered fix is applied to an incident it no longer matches. Because an agent can score well on both rates by doing nothing, safe resolution, how often it attempts a fix, escalation, and diagnostic effort and cost are reported alongside them. "Re-learned" and "no longer matches" are computed from the run logs against ground truth the environment generates, and the environment design note in November states both definitions before any results exist.
Data. No employer's or client's systems or data are used. Everything is run on the synthetic environment and open frameworks so that it can be reproduced. Synthetic results can show whether the mechanism works; a claim about production needs a further step, such as independently designed incidents or an operational benchmark like AIOpsLab, and each result will say which step it has reached.
Milestones. Written piece on problem 1 and the full protocol, November 2026: the environment, the comparators, ablations of each evidence signal, noisy and delayed feedback, and a table of related work. Public repository with the five policies and first results, January 2027. Preprint, March 2027. Each lands here and under its problem.
Nearest prior work: evidence-aware decay is argued for in Memory as a Controlled Process and benchmarked for personal agents in From Recall to Forgetting; the field is surveyed in A Survey of Agent Memory in the Second Half. Adaptive forgetting is an active research area. As far as I have found, none of these test it against recurring operational incidents under changing conditions; the November note sets out the comparison in full.
First piece due November 2026Each was met in production before it was written down. The first three are the programme the claim above belongs to. The other five are the governance questions that sit on top of a memory that holds; they are stated here so the boundary of the work is visible, and they are not in scope until the first three have results.
Each problem moves through four stages: Observed → Protocol → Evidence → Resolved. Observed means met in production; Protocol means the test is published before it is run; Evidence means the results are public, whichever way they fall. Nothing is called resolved before its evidence is public.
Protocol due November 2026
A remediation agent fixed the disk-pressure alert on Tuesday. The following Tuesday it rediscovered the fix from scratch. The run logs are there; the learning didn't persist.
Persisting the lesson means deciding what the lesson was: the fix, the symptom, or the context that made the fix safe. Store too little and it re-learns; store too much and it applies Tuesday's fix to a different Tuesday. Question: what is the unit of a lesson, and what evidence promotes it from one run's context to standing memory? This is the re-learn-rate metric in the claim.
Protocol due November 2026
Most memory in production agents only accumulates. Adaptive forgetting is an active research area, but it is rarely tested on recurring operational work, where a long-running agent that never forgets ends up steering by stale context.
Humans forget by a relevance decay they don't control. For an agent the decay rule has to be written explicitly, and every rule is a guess about which future situations will matter. Question: what evidence from the agent's own record should a decay rule answer to? This is the claim itself, and the stale-fix-rate metric.
Protocol due November 2026
Five agents share a memory store. One mis-reads a log and writes a confident wrong conclusion. Within an hour four agents are acting on it, and none can tell the entry came from a bad read.
Provenance and confidence have to travel with the memory, and the receiving agent has to weigh them under time pressure. Question: how far does one bad entry propagate, and what representation makes contamination detectable before it does? The second experiment: the same environment with a shared store and one injected bad entry.
The agent closes a fixed share of incidents on its own and cannot grow it. Model capability, permissions and tooling all play a part, but one gap a better model does not close on its own: nobody can state, in advance, which incident classes the agent is trusted on and why.
Trust has to be graded per capability and per blast radius, and the grading has to update as the agent's record changes, without a human re-reviewing every case. Question: what does a trust grade look like that an agent's own history can move, up and down? It depends on a memory that holds, which is why it waits for problems 1 to 3.
The AI usage policy says agents don't touch production data without approval. The agent read it during onboarding and never again. Policy lives in a wiki; the agent lives in a tool call.
Enforcement at the tool boundary works for coarse rules. The ones that matter, proportionality, context, 'fine in staging but not here', are judgements. Question: what representation of policy can live in the agent's memory and be consulted at decision time rather than at onboarding?
An agent that improves from experience changes the thing the evals were written against. After a few cycles the harness is green and the behaviour has drifted somewhere the harness never looked.
Evaluation has to improve at the same rate as the agent, or the agent is grading itself. Question: who writes the harness for the harness, and what signal tells you the harness has gone stale before the behaviour does?
The agent remembers every run. The human remembers why the run exists, what the business would never accept, and which failure is embarrassing versus dangerous. None of that is in the logs.
That knowledge has to enter the loop without the human becoming the bottleneck; approvals don't scale and written policy is not consulted. Question: what is the interface where human judgement is cheap to give and binding when given, and how does it persist as a memory the agents cannot decay?
Once improvement runs faster than a review cycle, the question stops being 'did a human approve this' and becomes 'can a human see what changed, and stop it, in time to matter.'
Safe by design means the agent cannot take the harmful action even when it is part of a process it is executing. Most processes were written for people who would notice. Question: what do observability and a stop look like for a loop faster than the person watching it?
Twenty years in production infrastructure, site reliability and cloud engineering, most recently leading platform engineering for a business-intelligence SaaS.
There I ran the entire production estate for 3,000 corporate customers and 45,000 daily users: 30 cloud accounts, six Kubernetes clusters, four database engines, identity, observability, disaster recovery and the AI serving layer, with a six-person senior team and a $3M budget.
Before that: Kubernetes, AWS networking and AI operations at a global accounting platform, including a cross-model incident operator; five years of site reliability at 4,000 deployments a year across hybrid cloud for a board-governance platform; an eleven-engineer platform team for six embedded radio product lines; platform tooling at a global bank. Business intelligence, financial software, board governance, embedded hardware and banking.
The thread through all of it: systems that stay tuned and keep improving by themselves, without losing what keeps them safe. This research is where that thread now lives, worked on independently and in the open.
Education: BSc (Hons) in Information Technology, Sri Lanka Institute of Information Technology (SLIIT).
Working method: agents write the code; I write the harnesses, evaluation rubrics and guardrails that decide whether it ships. For systems that improve themselves, I keep that improvement stable with outer loops that sit outside the improving loop and check it: one loop improves, separate loops govern what it may change, measure whether it got better, and stop it when it did not. The research uses the same discipline: the environment and the metrics are written before the decay rule is.
Gold medal, National Best Quality Software Awards (NBQSA), 2008.
Special recognition, Asia Pacific ICT Alliance Awards (APICTA), 2008.
Microsoft Excellence Award, 2009.
Silver, Microsoft Imagine Cup, 2007.
The research is privately funded: a small number of contract engagements pay for it. Research is the primary work. I welcome research grants, sponsors and collaborators.
What a sponsor gets. The waste happens here, once, instead of in your estate. A sponsor sees what is possible, what is working and what to avoid in how a company's memory is handled across agent swarms and the people who work with them, before spending on it themselves, and gets an early briefing on the results and can apply them to their own agents as the first live test. There is no exclusivity: the research results are published, so that nobody else has to spend the same money and time finding them.
Support can go to the programme as a whole or to a specific result; the three areas below are where it would land fastest, and they are examples rather than the only options.
Problems 1 and 2. Target: the synthetic incident environment and five memory policies as a public repository with first results, January 2027; a preprint, March 2027.
Problem 3. Target: the same environment with a shared store and injected bad entries, measuring how far one bad entry propagates under each policy and what representation makes it detectable first. Follows the first results.
Problem 4, the first of the governance questions, and the one a funder with a production estate would gain most from. Target: a graded-trust design tested against the environment, after the memory results hold.
Results flow one way. What the research finds is published: the results, the benchmarks, the test environment and the evaluation code. Products or tools I build on top of the findings are separate, and are not covered by this commitment. Nothing observed inside a client's or partner's system becomes research data without written agreement, and I do not validate a system I was paid to build or helped build within the previous twelve months, and I disclose any other interest.
If the results point to something worth building, I may build it, as a separate commercial product. The protocol, evaluation code and data stay public, so the findings can be checked without trusting me.
If you fund independent researchers, run an estate where these problems are live, or work on these questions yourself, I would like to hear from you.
Email info@gehanpanapitiya.comI reply within one working day, New Zealand time. Or message me on LinkedIn.