Researchers Propose Anti-Persistence: LLM Agent Memory Without Stored Rules

LLM-based agents can learn without fine-tuning: they write their runs to an external memory and use them on later tasks. But the more ready-made rules, summaries, and skills that memory accumulates, the greater the risk that a single error starts reproducing itself. The authors of a recent paper on Hugging Face Daily Papers call this effect error reproduction. Their answer is a memory design called Anti-Persistence: trajectories and outcomes accumulate, while task-specific guidance is rebuilt from scratch and thrown away after execution. According to the authors, across several benchmarks and backbone models, the design delivers the highest overall success on held-out tasks and the lowest average cost in LLM calls among the memory variants compared.

How an error reproduces itself

Agent memory designers usually choose between two options: store only raw trajectories with their results, or add derived abstractions on top of them. Abstractions are convenient because the agent does not have to extract a strategy from long logs every time. The price is that a wrong rule enters the context through memory retrieval and influences decisions.

Then the worst part begins. Decisions made under the influence of a bad rule produce new trajectories. The agent derives new abstractions from them, and those repeat the original error. Deleting or fixing the original rule does not solve the problem: the error is already recorded in the accumulated trajectories and will resurface in the "abstraction – execution – re-abstraction" loop. The authors describe this as extending the life of an error beyond direct reuse of the faulty knowledge.

What Anti-Persistence does

The idea is to separate two things: accumulating experience and permanently storing conclusions drawn from it. The memory stores trajectories and outcomes. Guidance for a task is synthesized at query time. An adaptive selector looks at past outcomes and decides whether a hint needs to be generated at all, and in what form. Once the task is done, the hint is deleted and cannot be reused as a stored object.

The authors openly acknowledge a residual risk: indirect feedback remains, because the hint influenced the trajectory and the trajectory stays in memory. The design weakens the loop but does not eliminate it.

What the abstract claims:

• Stored: trajectories and execution outcomes; derived rules, summaries, and skills are not stored.
• Guidance is synthesized on demand, for the specific task.
• The adaptive selector relies on past outcomes and chooses whether a hint is needed and of what type.
• Result: the highest overall success on held-out tasks among the memory designs compared.
• Cost: the lowest average price in LLM calls.
• Evaluation was run across several benchmarks and backbones.

The abstract gives no specific percentages or benchmark names, so the size of the gain cannot be assessed yet. You will need to check the full text of the paper and its tables.

What to check in your own agent

If you are building an agent with self-learning memory, the paper offers a few practical pointers.

First: separate the "experience log" from the "conclusions layer" in your architecture. You can accumulate the log without limits, but the conclusions layer is better treated as a cache that can be reset, not as a source of truth.

Second: when debugging agent degradation, check more than the rules themselves. If a corrected rule did not help and errors keep coming back, the culprit may be the trajectories produced under that rule's influence.

Third: watch the cost. Intuitively, synthesizing hints on the fly looks more expensive than using ready-made rules. The authors claim the opposite: in their tests this design was the cheapest in number of LLM calls, probably because the selector skips unnecessary syntheses and the memory is not bloated with abstractions. This hypothesis is worth testing on your own workload.

Finally, the result applies to specific benchmarks. Before rewriting your production memory, run an A/B comparison of Anti-Persistence against skill storage on your own tasks and see how success on held-out tasks changes over time.