TL;DR
ReHarness is a way to maintain an agent’s memory of short “lessons” (takeaways from past tasks) so that they get updated instead of just piling up. After each new task, a separate pass takes the lessons the agent used and checks whether they helped or hurt. Then it rewrites them: adds conditions of applicability, strips out overly bold generalizations — but relies only on the task the lesson originally came from.
Ordinary memory runs one way: solve a task, write down a takeaway, pull it out later. A recorded lesson is almost never re-checked after it gets reused. The takeaway “put the big numbers first” was derived from a descending sort. Then an ascending sort comes along, the lesson misleads the agent, and it stays in memory and keeps doing damage. When tasks shift, stale, overconfident lessons repeat the same mistake over and over. In the experiments, many “structured memory” methods turned out worse than an agent with no memory at all.
The method adds one more step to the usual “read → solve → write” loop: backward revision. Three steps total: retrieve lessons and solve the task, rewrite the lessons you used based on the outcome, write a new lesson from this task. The key revision rule: any new content in a lesson must be supported only by the original task it came from. The current task serves only as a “did it work or not” check.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1 (forward read): retrieve the k most similar lessons → agent solves the task → we get the outcome
STEP 2 (backward revision): for EACH lesson used, take
[lesson + the original task it was derived from + outcome of the current task]
→ rewrite the lesson: add conditions, cut what doesn’t belong
(new facts — only from the original task)
STEP 3 (forward write): write a NEW lesson from the current task,
using the already-revised lessons as examples
→ into memory: revised old ones + the new one
Each step is a separate model call (in the authors’ implementation, an automated pipeline).
Example
Task: An Amazon seller keeps a “lessons” file in a Claude Project for generating product listings. The first lesson came from power banks: “numbers (capacity) and the main keyword in the first 3 words of the title, no emoji.” Later the same lesson was applied to kids’ clothing. The title came out dry and conversion dropped. The lesson stayed in the file and will pop up again on the next clothing listing.
Prompt:
You are a reviewer of “lessons” for generating Amazon product listings.
LESSON THAT WAS USED:
“Numbers (capacity, size) and the main keyword in the first 3 words of the title. No emoji.”
ORIGINAL TASK THE LESSON WAS DERIVED FROM:
Listing “Power Bank 20000 mAh”. The version with numbers and the keyword up front
got a 6.1% CTR vs. 4.3% for the “emotional” title.
CURRENT TASK AND ITS OUTCOME (use only as a check, not as a source of facts):
Listing “Kids’ All-Season Jumpsuit”. Title following the lesson: “Jumpsuit 18M
All-Season for Toddlers”. CTR 2.2% vs. a category average of 4.0%.
REVISION RULES:
1. Decide whether the lesson held up, was too general, or is outdated.
2. If too general — add conditions of applicability (“electronics only,”
“when the shopper chooses by specs”).
3. Any new statement in the lesson must follow from the ORIGINAL task.
Do not carry facts from the current task into the lesson.
4. Don’t invent reasons that aren’t in the data. If the data isn’t enough,
say so: “hypothesis, not confirmed.”
RESPONSE FORMAT:
- Verdict (confirmed / too general / outdated)
- What exactly in the original task supports the edit
- Revised lesson (1-3 sentences, with conditions of applicability)
Result: The model will give a verdict and briefly explain what it’s based on. Then it will provide a rewritten lesson with a restriction: the rule about numbers and keywords applies to electronics where shoppers choose by specs. If the original task has no data about clothing, it will honestly flag that as a hypothesis. In a second request, ask it to write a new lesson from the current task (step 3).
Why it works
The weakness. A model writing a lesson after a single task tends to generalize: “this worked, so it’ll always work.” Such a lesson later looks like established fact and leads the agent astray. If you only ever add lessons, the old wrong one keeps surfacing next to similar queries. A new lesson doesn’t cancel it.
The strength. Models are good at comparing a lesson’s text with the actual outcome and finding what the lesson was missing. Give one both the original task and the result of the new one, and it does a decent job of writing conditions of applicability. That’s ordinary text work, not forecasting.
How the method exploits this. The revision gets feedback: the new task shows where the lesson tripped up. The “new content only from the original task” constraint keeps the model from simply writing the fresh answer into the lesson or overfitting it to a single data point. In the authors’ check, over 95% of statements in revised lessons remained supported by the original task.
Knobs: - Number of lessons per revision (k) → fewer lessons is cheaper, but some errors won’t get fixed. - The “only from the original task” rule → loosen it and the lesson starts bending to the latest case. Keep it strict. - Outcome signal → the more precise the outcome (CTR, accepted or rejected by the client, tests passed), the better the revision. The noisier the outcome, the less useful it is. - Verdict format (“confirmed / too general / outdated”) → handy for filtering which lessons to change.
Prompt Template
This is a reconstruction based on the paper’s description. The authors put the exact prompt texts in Appendix A, which isn’t in the excerpt provided.
<Role>
You are an agent memory reviewer. Your job is to check whether a recorded lesson
has become harmful or outdated, and rewrite it with conditions of applicability.
</Role>
<Input>
<Reflection>{lesson_that_was_used}</Reflection>
<SourceTrajectory>{original_task_and_its_outcome}</SourceTrajectory>
<CurrentTrajectory>{current_task_answer_and_outcome}</CurrentTrajectory>
</Input>
<RevisionLogic>
1. Compare the lesson with the outcome in CurrentTrajectory: did it help, hurt, or have no effect?
2. If it hurt or had little effect — find what the lesson was missing:
• overlooked evidence from SourceTrajectory;
• an overly bold generalization;
• missing conditions of applicability.
3. Rewrite the lesson so that with it the agent would not have made the mistake in CurrentTrajectory.
4. HARD RULE: CurrentTrajectory is a check only.
Every new statement must be supported by SourceTrajectory.
If the data isn’t enough — mark it “hypothesis.”
</RevisionLogic>
<OutputFormat>
Verdict: confirmed / too general / outdated
Basis from SourceTrajectory: {...}
Revised lesson: {1-3 sentences with conditions}
</OutputFormat>
<!-- Step 3, as a separate request: -->
<ForwardWrite>
Here are the revised lessons: {revised_lessons}.
Here is the current task: {current_task_and_outcome}.
Write ONE new lesson. Keep only what the data supports.
The lesson should complement the revised ones, not repeat them.
</ForwardWrite>
What to fill in: {lesson_that_was_used} — an entry from your lessons file. {original_task_and_its_outcome} — the material the lesson was derived from. {current_task_answer_and_outcome} — the fresh case where the lesson was applied, with its outcome.
🚀 Quick start — paste into a chat:
Here is the ReHarness template (revising an agent’s “lessons”). Adapt it to my task: {describe what agent you run and what lessons it accumulates}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask where your task outcome comes from (a metric, a client decision, a check) and where the lessons are stored. The revision needs this: without an outcome there’s nothing to check, and without the original task there’s nothing to back up the edits. It will tailor the role, verdict format and fields to your domain.
Limitations
⚠️ You need a clear outcome signal: the method works best when the outcome is diagnostic: the task was solved or not, tests passed or failed. Where the result depends heavily on chance (in the experiment, poker with hidden cards), the gain was only small. Revising based on a single random outcome makes lessons worse.
⚠️ You need a pipeline, not a single prompt: in the paper this is an automated loop with embedding-based retrieval of similar lessons and separate model calls. In a regular chat you can only reproduce it by hand, one or two tasks at a time.
⚠️ Gain over raw history is modest: storing raw past cases turned out to be a strong baseline. ReHarness beats it, but statistical significance is borderline. If you have few tasks, it’s simpler to put the whole history in context.
⚠️ More expensive than simple similar-case retrieval: on the Claude tasks, the method cost about three times more than “retrieve a few similar cases” (roughly $254 vs. $85 per run), but less than the full history (about $314).
⚠️ Conventional “smart” memory doesn’t guarantee a benefit: methods that extract facts or maintain a “rulebook” in some cases performed worse than an agent without memory. Don’t assume that recording lessons by itself makes an agent better.
How the research was done
The idea was simple: if an agent’s memory only ever grows, wrong lessons live forever. The authors took three sets of streaming tasks, where the agent solves a sequence of assignments and must learn as it goes: from working with code and databases to long texts and planning. That came to 16 tasks in total. They tested on three current models and compared against six competitors: Mem0, a lesson bank, ACE and others. There were also two “raw” variants: the entire history and similar cases only. The metric was normalized gain over the same model without memory. The stream ran strictly online: no training or validation splits and no second pass over the tasks.
ReHarness showed the best average gain (0.240 vs. 0.168 for the best baseline) and took first place or tied for it in eight of nine “task set — model” combinations. The surprise was that raw history beat many “smart” methods that store takeaways. In other words, poorly maintained lessons are worse than no lessons.
To verify that the revision doesn’t “peek” at the answer, the authors broke revised lessons down into individual statements. Over 95% of them were supported by the original task, and leakage from the current one was about 1-2%. A counterfactual test gave an even stronger result. The revised lesson was applied to the same task it had been revised on. The gain rose to 0.335 vs. 0.144 without revision. So the edits really do contain the needed information. Practical takeaway: revision works when the outcome is diagnostic, and is weakest where the result is noisy.
Adaptations and extrapolations
🔧 Technique: rules in CLAUDE.md / AGENTS.md → conditions of applicability instead of eternal rules
After a session with an agent (Claude Code, Cursor), paste this into a chat:
Here are the rules from my instructions file that the agent applied in this session: {rules}.
Here is what ended up happening: {outcome: what went wrong, what worked}.
For each rule: confirmed / too general / outdated.
Rewrite the too-general ones with the condition “apply only if…”.
Don’t add anything that isn’t in the history the rule was derived from.
This is a manual version of revision for an instructions file. The paper tested the idea on an automated pipeline; carrying it over to instruction files is our extrapolation.
🔧 Technique: the “would the lesson have prevented the mistake?” check → quick diagnostics
An idea from the paper’s counterfactual test:
If the revised version had been in memory instead of the old lesson, would it have prevented the mistake in this task? Yes/no and why.
If “no,” the edit is useless and better discarded.
Resources
- Recurrent Harness for Agentic Continual Learning (ReHarness). The authors and university are not listed in the excerpt provided. The prompts are published in Appendix A of the paper.
- Benchmarks used for evaluation: CL-Bench (Asawa et al., 2026), MemoryBench (Ai et al., 2026), MemoryArena (He et al., 2026).
- Competing methods: Mem0 (Chhikara et al., 2025), ACE (Zhang et al., 2026c), GEPA (Agrawal et al., 2026), Diversity of Thoughts DoT (Lingam et al., 2025), lesson bank RBank (Ouyang et al., 2026).