In short
- An agent can store a bad rule, let that rule shape a later run, and then infer a fresh rule from the distorted run. Deleting the original rule may no longer remove its influence.
- A recent preprint calls this mechanism error reproduction. Across nine benchmark and model settings, its anti-persistence design led seven and had the best equal-weight average success rate.
- Anti-persistence does not erase experience. It keeps tasks, trajectories, and outcomes, generates guidance for the current task, and discards that guidance after use.
- For enterprise agents, memory needs provenance, outcome labels, expiry rules, and review. A polished summary should not automatically outrank the evidence that produced it.
At 9:14 on a Monday morning, an enterprise agent opens a supplier portal, a signed purchase order, and an email amendment. The three records disagree.
The portal says a component will arrive in two weeks. The purchase order says six. The email, approved after the purchase order was signed, says four. The agent chooses the wrong date and the task is marked unsuccessful.
Before moving on, the system performs the ritual that makes modern agents look as if they can learn. It reviews the run. It writes a concise lesson for the future: When delivery dates conflict, trust the signed purchase order.
The sentence is neat, general, and wrong.
A week later, another supplier record contains the same pattern. The agent retrieves its lesson, ignores a later approved amendment, and fails again. That second execution now enters memory too. When the system summarizes its experience, the new trajectory appears to confirm the old rule. What began as one mistaken explanation has acquired a history.
This scene is illustrative, but the failure mechanism is real enough to have a name. In an October 2026 preprint, Ruhan Wang, Kishan Panaganti, and Dongruo Zhou call it error reproduction: an inferred rule changes later behaviour, the changed behaviour becomes new evidence, and a descendant rule carries the mistake forward. [1]
Memory is supposed to stop an agent from making the same mistake twice. Under the wrong design, memory can do something stranger. It can teach the mistake a second time.
A memory can preserve a fact or manufacture a rule
The easiest way to see the problem is to separate the objects hidden inside the word “memory.”
A trajectory is a record of an attempt. It may include the task, observations, tool calls, intermediate actions, and final result. In the supplier example, the trajectory contains the three dates, the records opened, the date selected, and the failed outcome.
An abstraction is an interpretation of one or more trajectories. It may be a summary, a reusable skill, a warning, or a procedural rule. “Trust the signed purchase order” is an abstraction. It compresses a messy episode into something cheap to retrieve and easy to follow.
An outcome is the external signal attached to the attempt. Did the task succeed? Did a verifier accept the result? How much did the run cost? The outcome does not explain why the result occurred. It anchors the memory to something beyond the agent’s own prose.
These objects have different strengths. A trajectory is rich but long. An abstraction is compact but interpretive. An outcome is decisive but often sparse. A system that stores only raw runs may waste context and struggle to extract the relevant pattern. A system that stores only conclusions may turn uncertain explanations into durable policy.
The new paper studies external memory with fixed model weights. The agent is not retrained after every task. Its apparent self-improvement comes from what the surrounding system saves, retrieves, and places into the next prompt.
That boundary matters. The work is not evidence that neural networks should never learn from previous examples. It is evidence that a particular software layer can create a feedback loop even when the underlying model does not change.
The dangerous step is re-abstraction
Direct reuse is easy to notice. A bad rule sits in a database. Retrieval finds it. The agent follows it. An engineer can inspect the rule, delete it, or lower its score.
Error reproduction is harder because the rule can leave descendants.
Suppose a stored abstraction says to trust a signed document over a later message. The next agent follows that instruction. Its resulting trajectory now includes a confident decision to ignore the message. A later synthesis process reviews the trajectory and writes a new rule: Approved delivery estimates should come from formal procurement records, not informal correspondence.
The wording has improved. The evidence has not.
Deleting the first sentence no longer deletes the second. Nor does it revise the runs produced while the first rule was active. The system needs provenance across generations: which stored item influenced which action, which run produced which summary, and which external outcome challenged the result.
This is familiar outside AI. A spreadsheet error becomes a slide, the slide becomes a target, and the target becomes the premise of next quarter’s forecast. Each transformation removes detail and adds authority. By the time the original cell is corrected, the organization has already built several decisions on top of it.
Agent memory makes that process faster. A summary can be written after every run and retrieved before the next one. The useful compression is also the route by which uncertainty disappears.
Remember the evidence, rebuild the lesson
The paper’s answer is called anti-persistence. The name sounds like deliberate amnesia. The actual design is more careful.
The system retains tasks, trajectories, and outcomes. For a new task, it retrieves related records and decides how to use them. It may supply the records directly. It may extract a behavioural pattern from successful attempts. It may build a higher-level strategy. Or it may compare failures with a success and generate corrective guidance.
The guidance helps with the current task and is then discarded. The next task returns to the evidence and constructs a new interpretation for its own context.
The selector also learns which mode has worked for similar tasks. Its outcome log records the task, chosen mode, raw result, cost-adjusted reward, and time. Recent, relevant outcomes influence whether the system should imitate, plan, correct, or simply show the retrieved runs without another synthesis call.
That is the useful distinction. Anti-persistence does not deny the value of abstraction. It denies every abstraction an automatic right to become permanent.
More stored guidance performed worse in this test
The researchers compared four memory configurations across ALFWorld, WebShop, and ScienceWorld. These are text-based environments involving household tasks, online shopping, and elementary science procedures. The backbones were Llama-4-Scout, Qwen3-Coder-Next, and Gemma-4-31B-it. Each reported result averages three seeds. [1]
Trajectory memory retrieved past executions. Abstraction memory retrieved stored inferred guidance. Joint memory retrieved both. Anti-persistence retained trajectories and outcomes but rebuilt guidance as needed.
Across the nine benchmark and backbone combinations, anti-persistence had the highest success rate in seven. Its equal-weight average was 59.9%, compared with 53.5% for trajectory memory, 49.0% for abstraction memory, and 49.3% for joint memory.
The result does not prove that stored skills are always harmful. It shows that adding persistent abstractions did not reliably improve these agents under this procedure. In seven of nine settings, abstraction memory and joint memory both trailed trajectory memory.
A smaller controlled test helps explain why content matters. On 30 AppWorld tasks, Qwen3-Coder-Next succeeded on 23% without supplied skills, 40% with a constructed useful skill library, and 20% with a matched “toxic” library containing incorrect rules. The labels describe experimental conditions, not a production safety category. The test shows an immediate effect of supplied guidance; it does not by itself establish a long-term reproduction rate.
The study also compared discarding and persisting generated abstractions in four Llama and Qwen settings across ALFWorld and WebShop. Discarding won in all four. The gains ranged from 3.3 to 28 percentage points. That result is striking, but its scope is still four combinations inside a fixed experimental procedure.
There is a second surprise. Anti-persistence used the fewest LLM calls on average among the four memory configurations while also producing the highest average success. It sometimes reused a trajectory directly, without paying for a synthesis call, and shorter successful runs could offset the calls used to create temporary guidance.
More thinking was not automatically better. More retrieved records were not automatically better either. In a Qwen sensitivity test on ALFWorld and WebShop, retrieving five trajectories beat retrieving one or ten. The authors suggest that too little context makes the agent sensitive to individual examples, while too much weakly related context may dilute the useful signal. The sweep is consistent with that explanation; it does not isolate it.
The tempting rule is “never store a rule”
That conclusion is too neat.
A reliable procedure may be worth retaining. A verified escalation path, a tested database migration, or a legally approved calculation should not have to be rediscovered from raw logs every morning. Durable knowledge is one reason organizations write manuals instead of preserving only meeting recordings.
The paper acknowledges the cost. Discarding abstractions gives up the benefit of reusing dependable knowledge. Anti-persistence also leaves an indirect path for feedback. Temporary guidance can shape a run, and the run remains in trajectory memory. A future synthesis step can still inherit the distortion.
Its performance depends on retrieval quality and experience coverage. If the relevant successful case is absent, mislabeled, or never retrieved, rebuilding guidance cannot recover it. The main experiments cover three text environments, three fixed backbones, ten memory-update rounds, and a fixed improvement procedure. Long-term behaviour, multimodal agents, production tools, and changing business policies remain outside the evidence.
Even the most persuasive numbers require care. The paper’s auxiliary controlled studies do not provide task-level or seed-level uncertainty estimates. Its setting-level statistical analysis is exploratory because the nine cells share backbones and benchmarks. This is a serious preprint with unusually explicit limits, not a settled law of agent architecture.
An enterprise memory needs a chain of custody
The useful enterprise response is not a blanket ban on summaries. It is a retention policy for machine-generated knowledge.
First, preserve source and interpretation separately. A rule should link back to the exact trajectories, tool outputs, document versions, and outcome labels that support it. If the source record changes, the system should know which descendants may be stale.
Second, attach scope. “Trust signed purchase orders” is dangerously broad. “For supplier X, when no approved amendment exists, use the signed purchase order’s delivery date” is narrower and testable. Scope should include task type, system state, policy version, jurisdiction, customer segment, and time where they matter.
Third, make success external. An agent’s fluent postmortem cannot validate its own lesson. A completion signal may come from a deterministic check, a transaction outcome, an expert reviewer, or a held-out grader. The right source depends on the work, but it should not collapse into the same model-generated paragraph it is meant to judge.
Fourth, give abstractions an expiry date. Temporary by default is a strong starting point for newly inferred guidance. Promotion to durable memory can require repeated support, independent examples, review, or a confidence threshold calibrated on held-out tasks.
Fifth, collect counterexamples deliberately. A rule that succeeds ten times under one narrow condition may fail immediately when a later amendment exists. Evaluation should search for those boundary cases instead of rewarding a memory system for retrieving increasingly similar confirmations.
| Memory object | What should travel with it | Default enterprise treatment |
|---|---|---|
| Trajectory | Task, observations, actions, tool outputs, environment version | Retain with access controls and provenance |
| Outcome | Success criterion, verifier, score, cost, timestamp | Retain separately from the agent’s explanation |
| Abstraction | Supporting records, scope, author or model, creation time | Expire unless verified or promoted |
| Durable rule | Owner, approval, test cases, policy version, review date | Treat as governed operational knowledge |
This is where data work becomes memory engineering. A useful trajectory dataset needs more than a transcript of actions. It needs outcomes that reflect the real task, failure labels precise enough to support correction, examples that expose policy boundaries, and reviewers who can distinguish a plausible explanation from the reason the work actually failed.
Perit’s broader premise, that training data and evaluations should be built with people who perform the work, applies directly here. The person who knows whether a supplier amendment outranks a purchase order can define the edge case, label the outcome, and reject a seductive but false generalization. Without that expertise, the memory layer may merely compress organizational misunderstanding.
Correcting the first rule may not correct the system
Return to the supplier example after an analyst discovers the problem. The team deletes the rule about trusting signed purchase orders. That is necessary. It may also be far from sufficient.
The rule influenced later runs. Those runs may have produced new summaries, changed supplier records, opened tickets, or triggered messages to colleagues. Some descendants live inside the agent’s memory. Others have already escaped into ordinary business systems.
This makes correction a graph problem. A stored abstraction should have outgoing links to the tasks in which it appeared. Each resulting trajectory should link to the new memories, records, and actions it produced. When a root item is withdrawn, the system can identify what needs review instead of assuming that deletion travels backwards through history.
Database engineers already use a related idea. A materialized view depends on underlying tables. When the source changes, the view may need to be refreshed. Agent memory creates materialized interpretations: compact conclusions derived from a changing set of events. Without dependency tracking, a correction updates the source while stale interpretations continue to circulate.
Not every descendant needs to be erased. Some later decisions may remain valid for independent reasons. The practical choices are more precise: invalidate the item, lower its retrieval priority, rerun the affected task, request expert review, or preserve it with a warning for audit purposes.
The important property is reversibility. A team should be able to answer four questions: Which memory influenced this action? Which evidence produced that memory? Which later records inherited its assumptions? What happened after the correction?
These questions turn provenance from documentation into an operational control. They also change the data schema. A flat list of summaries is insufficient. The memory store needs lineage identifiers, versioned policies, timestamps, outcome references, and a record of promotion or revocation decisions.
The agent should not merely learn. The organization should be able to unlearn with precision.
The system should be tested across generations
Ordinary agent evaluation resets the world after each task. Memory systems require a different test. The unit is not one answer. It is a lineage.
Start with a clean memory store and a controlled set of tasks. Introduce one ambiguous failure. Record the abstraction generated from it. Then measure the later tasks that retrieve the abstraction, the actions that change, and the new summaries produced from those actions.
The critical metrics are not limited to task success. Count how often unsupported guidance is admitted, how many later runs are exposed to it, whether descendants reproduce the same error, and how quickly a correction removes the influence. Measure false promotion too: useful rules that never become durable can waste cost just as harmful rules can waste accuracy.
Run the test with policy changes. A rule can be correct when written and harmful six months later. Update the source document, leave the stored abstraction untouched, and see whether the agent prefers the newer evidence or its older lesson.
Finally, audit retrieval. A memory can be perfectly written and still arrive in the wrong context. Similar wording does not guarantee the same operational condition. The study’s own budget sweep hints at this: adding more records can reduce performance when relevance becomes diffuse.
Back to the copied card
The first mistake on the archive desk is visible. A red pencil can cross it out.
The second card is more dangerous. It contains a clean sentence copied from the first, stripped of the hesitation and conflicting evidence that made the original decision uncertain. The third card looks like policy.
That is the real risk in agent memory. Storage does not merely preserve the past. It chooses a representation of the past, gives that representation authority, and places it inside the next decision.
A capable agent should learn from experience. A reliable system must also remember which parts were observed, which parts were judged, and which parts were only inferred.
Keep the record. Verify the lesson. Let unproven conclusions expire.
Sources
- Ruhan Wang, Kishan Panaganti, and Dongruo Zhou, “More Memory, Worse Agents: Error Reproduction and Anti-Persistence in LLM Agents”, submitted 19 October 2026. The full HTML paper supplies the method, benchmark counts, results, auxiliary analyses, and limitations discussed above.
- Guannan Lai, Zi-Yang Bai, Jun-Peng Jiang, and Han-Jia Ye, “Remembering Has a Price: Learning Memory Worth under Resource Constraints”, submitted 19 October 2026. This separate study examines which experiences are worth retaining when generation, interaction, and memory budgets are jointly constrained.
Research checked 21 October 2026. The empirical results are author-reported and were not independently reproduced by Perit. The supplier scenario, archive-card metaphor, and enterprise evaluation plan are illustrative. The central study concerns external memory with fixed model weights, three text-based benchmarks, and a fixed improvement procedure; it does not establish that all persistent knowledge or all long-term memory is harmful.
