Anti-Persistence: Keep the Agent's Raw Records, Rebuild Conclusions and Rules for Each Task, Then Throw Them Away

STORED PERMANENTLY:
  • record log: task → actions → outcome (success/failure)
  • mode log: which hint mode → how it turned out

FOR EACH NEW TASK:
STEP 1: find similar past tasks in the mode log → pick a mode
        (none / imitation / strategic / corrective)
STEP 2: pull matching records from the log → a set of examples
STEP 3: build a temporary hint according to the mode (or pass the records as is)
STEP 4: solve the task with this hint
STEP 5: THROW the hint AWAY; save the record and the outcome

The four modes: - none — just pass along the retrieved records with no extra processing. - imitation — extract action templates and the conditions for using them from successful records. - strategic — build subgoals and a plan from successful records. - corrective — analyze failed records and spell out what to avoid. A successful record is added for contrast.

In the original this is code: similarity search plus a switch that tries out modes. But the principle "keep the records, throw away the conclusions" works by hand too. It fits no-code automations and setting up agents like Claude Code.

Where the method shines: repetitive tasks where every run has a clear outcome (worked / didn't work) and the agent accumulates experience. One-off creative tasks are not a fit.

Task: You run the returns desk at an online electronics store (an Amazon storefront plus your own site). An AI agent handles customer requests. It used to append "rules" to a file after every case, like "always refuse customers whose receipt is older than 14 days." A month later the rule was being applied to warranty cases too, and complaints went up. Now you keep only a log of cases with outcomes, and the agent builds a fresh hint for each case.

Prompt:

<Role>
You are a support agent for an online electronics store. You do NOT rely on
saved rules. You rely only on the log of past cases.
</Role>

<NewCase>
A customer from Denver writes: "Bought headphones 18 days ago, the right one stopped
playing. I have the receipt in my Amazon app. I want a refund, $89.99."
</NewCase>

<RetrievedCases>
Case 1 (outcome: SUCCESS): headphones, 20 days, defect confirmed by video → 
warranty exchange, customer happy.
Case 2 (outcome: FAILURE): speaker, 16 days, refused "14-day window" → 
complaint, escalation, refund via formal claim.
Case 3 (outcome: FAILURE): smartwatch, 19 days, offered a refund instead of 
checking for a defect → lost money on a non-defective item.
Case 4 (outcome: SUCCESS): headphones, 12 days, defect → quick refund.
</RetrievedCases>

<ModeHistory>
corrective on similar cases: 3 times, average result +0.8
imitation on similar cases: 2 times, average result +0.3
none on similar cases: 1 time, result −0.5
</ModeHistory>

<Task>
1. Pick a mode (none / imitation / strategic / corrective) based on ModeHistory.
   Briefly explain your choice. It's worth trying a rarely used mode
   if there is little data on it.
2. Build a TEMPORARY hint for this case only, according to the chosen mode.
   In corrective mode: analyze the failed cases, what exactly went wrong,
   and spell out what to avoid; use the successful case as a contrast.
3. Reply to the customer with the hint in mind.
4. At the end, write: "This hint is temporary and is not saved to memory."
   Only the record gets saved: case → actions → outcome.
</Task>

Result: The model names the chosen mode with a short rationale (most likely corrective, given the history). Then it gives a temporary hint block: what went wrong in cases 2 and 3, and how successful case 1 differs. Next comes a ready reply to the customer and a note that the hint isn't saved. You (or your automation) add only the record of the case and its outcome to the log.

Weakness. A conclusion like "always refuse after 14 days" rests on conditions that may not hold in another case. Once the agent saves such a rule, it confirms itself. The agent acts by the rule, and the records reflect those actions. At the next "lessons learned" pass, the same rule is derived from the records. Deleting the original rule isn't enough: the saved records and offspring remain.

The LLM's strength. The model is good at deriving patterns from a few examples right in context, tailored to a specific task. Raw records store what happened and don't pretend to explain it. Any conclusion drawn from them is checked against the current task every time.

How the method exploits this. It separates experience from conclusions. Experience piles up as facts. Conclusions live for one task and die with it, so an error never gets locked in as an object. The authors are upfront about the caveat: some influence remains anyway, because the records keep actions taken under the hint's influence.

Control knobs: - Number of records in context — fewer for simple tasks (cheaper), more for complex ones. - Set of modes — drop strategic if you don't have multi-step plans; keep only corrective if not repeating mistakes matters most. - Contrast — add a successful case to the failed ones: that way the model sees the difference, not just "what not to do." - Penalty for an extra call — in the original, an extra model call lowers a mode's reward. Want faster and cheaper? Nudge the choice toward the none mode. - Recency — in the original, older mode scores carry less weight. If your processes change often, count only recent cases.

<Role>
You are an agent for tasks of type {task_type}. You do NOT rely on saved
rules or conclusions. You rely only on the log of past runs.
</Role>

<NewTask>
{new_task}
</NewTask>

<RetrievedRecords>
{3-5 similar records: task → actions → outcome (SUCCESS/FAILURE)}
</RetrievedRecords>

<ModeHistory>
{for each mode: how many times it was used on similar tasks and how it turned out}
</ModeHistory>

<Modes>
none        — use the records as is, without processing
imitation   — extract action templates and conditions from SUCCESSFUL records
strategic   — build subgoals and a plan from successful records
corrective  — analyze FAILED records, what went wrong; spell out
              what to avoid; use a successful record as a contrast
</Modes>

<Task>
1. Pick a mode based on ModeHistory. Explain the choice in one sentence.
   If there is little data on some mode, you may try it.
2. Build a TEMPORARY hint for this task only, according to the chosen mode.
3. Solve the task with the hint in mind.
4. Output a record for the log: task → actions → outcome.
   Do NOT include the hint in the record.
</Task>

<Rule>
The hint lives only in this run. Do not phrase it as a rule
for the future.
</Rule>

What to fill in: {task_type} — the category (returns, code review, leads). {new_task} — the specific request. {records} — 3–5 similar past cases from your log (a spreadsheet, notes, Notion). {ModeHistory} — a simple "mode / times used / outcome" table. You can keep it by hand.

🚀 Quick start — paste into the chat:

Here is the Anti-Persistence template. Adapt it to my task: [your task]. 
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask which tasks repeat, what "success" and "failure" look like, and where your past cases are stored. It needs these answers so that log records have outcomes and the modes can be compared. It will take the pattern from the template and build a working prompt and log format for your task.

⚠️ Test environment: the experiments ran on training environments — household tasks in text (ALFWorld), shopping in a simulated store (WebShop), science experiments in a simulator (ScienceWorld). That's not a real business and not your CRM. Transferring this to support, code or sales is a hypothesis, not a result from the paper.

⚠️ Not better everywhere: the method won in seven of nine task–model pairs. In the rest it tied or lost (for example, with one model on one environment, Reflexion, ExpeL or rule-based memory came out ahead). The authors themselves say the best option depends on the conditions.

⚠️ Errors don't vanish completely: raw records store what the agent did, not what was right. If a hint was bad, its trace stays in the record. The method removes direct reuse of an error, not all of its influence.

⚠️ You need an outcome: without a "success/failure" label in the log, the mode switch and corrective mode are useless. If your tasks have no verifiable outcome, the method loses half its power.

⚠️ The full version is code: the real selector computes weights by similarity and recency and tries out modes. By hand you can reproduce the principle (keep records, discard the hint, pick the mode from a table), but not the exact math.

⚠️ Causality isn't proven: "error reproduction" is confirmed as a link between old and new rules, not as a rigorously proven chain. The text of the paper we have cuts off during the ablation analysis, so we didn't see the details of the control experiments.

The team tested the idea on three agent training environments and three open models. Each memory variant was run for 10 rounds of self-learning in three repeats. After each round, memory was frozen and success was measured on held-out tasks the agent never saw during training.

Four memory designs were compared: records only, derived rules only, records plus rules, and Anti-Persistence. Separately, they took four well-known competing agents: ReAct, Reflexion, ExpeL, AutoRefine.

The result was surprising: rules didn't help. On average, Anti-Persistence achieved 59.9% success, records only 53.5%, rules only 49.0%, records plus rules 49.3%. The best competitor, Reflexion, scored 52.9%. In other words, adding rules to records didn't improve the result and often made it worse: in seven of nine cases both rule-based variants lost to plain records. AutoRefine, which cleans up rules, improved the result in only one of six cases.

An important detail: Anti-Persistence turned out to be the cheapest in terms of model calls. The none mode needs no extra call, and with this method the runs themselves sometimes get shorter. The practical takeaway: storing experience is useful, but locking in conclusions drawn from it is risky.

🔧 Technique: audit the rules file → weed out "self-derived" rules

If your agent (Claude Code, Cursor, a custom GPT) appends its own "lessons" to CLAUDE.md or a memory file, check where they came from. This is my adaptation; the paper doesn't include such an audit.

Here is the agent's rules file: {file}
Here are the logs of recent runs: {logs}

For each rule:
1. Is it supported by SEVERAL different cases from the logs?
2. Is it phrased as universal ("always," "never") even though
   it's based on a single case?
3. Did it emerge as a result of actions taken under an earlier
   rule (a loop of "rule → actions → same rule")?

Return a table: rule / source / risk (low, medium, high) /
keep, rewrite or delete.

High-risk rules should be rewritten as conditional ("if X, then Y") or removed and returned to the log as facts.

Extrapolation: failures only + contrast. If you don't want to keep a mode log, you can use corrective alone. Before an important task, give the model 2–3 past failures and 1 success and ask: "Analyze what went wrong and how the success differs, and give warnings for this task only. Don't phrase them as a general rule." This is the cheapest way to get value from the method.

• Paper: More Memory, Worse Agents: Error Reproduction and Anti-Persistence in LLM Agents
• Authors: Ruhan Wang (Indiana University), Kishan Panaganti (Tencent HY), Dongruo Zhou (Indiana University)
• Approaches and environments mentioned: ReAct, Reflexion, ExpeL, AutoRefine; ALFWorld, WebShop, ScienceWorld
• Models in the experiments: Llama-4-Scout, Qwen3-Coder-Next, Gemma-4-31B-it