TL;DR
Hippo is a memory scheme for an agent. The agent solves the same task several times in a row. Lessons are recorded only from failures and “lucky wins”. Comparing the attempts yields a single rule with a condition of applicability. Then the new rule is checked against existing memory: duplicates get merged, contradictions resolved, stale entries deleted. The model's weights never change; everything lives in text.
The headline finding is an anti-pattern: if you record lessons from every task without cleanup, quality rises at first, then drops, and eventually ends up below an agent with no memory at all. There are two reasons. First, entries compete for space in the context, and the useful ones drown. Second, bad lessons sneak into memory. Say the answer is right but the path to it is wrong. Or a rule gets written down without the condition “when it works.” An example from the paper: the agent learned to “rank customers by the Order Count report.” It didn't note that the report counts all orders, while the question was about completed ones. On the first task this worked by luck; on the second it produced a wrong answer.
The second inconvenient fact: simply retrying already boosts the odds of success a lot. Picking the best of eight runs gives a noticeable gain with no memory whatsoever. So any “self-learning” method has to be benchmarked against an honest retry. Hippo turns this into an advantage: the divergence between attempts shows exactly which decision separated success from failure. The method in 3 steps: a judge picks out the “surprises,” an inductor compares attempts and writes a rule with conditions, a consolidator merges the rule into memory without duplicates or conflicts.
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 0: Run the task N times (same memory, same prompt) → N trajectories
STEP 1 (Judge): For each attempt: success AND correct reasoning?
yes → write nothing
no (failure OR “right for the wrong reasons”) → “surprise” → short reflection
STEP 2 (Inductor): Compare attempts on the same task → candidate lesson = decision + conditions of use
most succeeded → the minority's mistakes become warnings
few succeeded → what set the winners apart
even split → both the strategy and the trap
all failed → failure patterns only, no making things up
all succeeded → skip this step
STEP 3 (Consolidator): Find similar entries in memory → duplicate? discard.
Conflict? New entry with explicit conditions, the old one gets deleted
STEP 4 (Inject): For a new task, retrieve the top similar entries → the agent itself picks the applicable ones → into context
Steps 1–3 can be run as separate requests. In off-the-shelf agents, step 4 is done by attaching a memory file.
Example in Practice
Task: You run a store on Amazon and Shopify. Every week an agent in Claude Code builds a report from the data exports. It has messed up twice: it computed “revenue per SKU” across all orders, including canceled and returned ones. The agent has already piled up 40 entries in lessons.md. Some are duplicates, some contradict each other. You need to fold in a new lesson cleanly.
Prompt (step 3, consolidator):
You are the agent's memory consolidator. Your job: add the candidate lesson to the lessons file without creating duplicates or conflicts.
<Candidate>
Decision: compute revenue per SKU only from orders with status “Shipped, not returned” (Amazon) and “Fulfilled” (Shopify).
Conditions of use: questions about revenue, profit, margin, or ranking SKUs by money.
Do not apply: questions about “order count” or the funnel, which need all statuses.
Source: of 3 attempts, the 2 correct ones filtered by status, the 1 failed one used all orders.
</Candidate>
<SimilarEntries>
#12: To rank SKUs, use the “Sales by SKU” report and sum over the entire period.
#17: For revenue, use the “Ordered Product Sales” column.
#31: Reconcile Amazon reports against Seller Central, not against the monthly export.
</SimilarEntries>
Rules:
1. If the candidate duplicates an entry, discard it and write “duplicate #N”.
2. If the candidate contradicts an entry, create a new entry with explicit conditions (“when yes / when no”) and flag the old one for deletion.
3. Do not rewrite entries that are unaffected.
4. Do not add anything that isn't in the candidate.
Return:
ADD: [full text of the new entries]
DELETE: [numbers]
REASON: [one line per decision]
Result: The model will flag that #17 conflicts with the candidate: “Ordered Product Sales” includes orders that were later returned or canceled. It will suggest deleting #17 and adding a new entry with the status condition. #12 stays but may get a note about the condition. #31 is left alone. The response will have three blocks: ADD, DELETE, REASON.
Why It Works
The weakness. A single run doesn't reveal why something failed: was the strategy bad, or was a good plan poorly executed? A correct answer proves nothing either: it might have been luck. If you write a lesson from a single trajectory, it captures specific actions instead of the decision and lands in memory with no conditions of applicability. Later it gets pulled up as a “proven precedent” in places where it doesn't fit.
The LLM's strength. Models are good at comparing texts and spotting the difference: “in the successful attempts the agent checked the status, in the failed ones it didn't.” They're also good at checking two phrasings for duplication or contradiction. None of this needs training or new tools.
How the method exploits it. Comparing attempts turns “what the agent did” into “which decision mattered.” An explicit “when to apply” condition keeps a rule from firing where it's wrong. Consolidation keeps memory from bloating or contradicting itself. In the paper, Hippo stored 83 entries versus 270 for AWM and 665 for ReasoningBank, and still got better results.
Control knobs: - Number of attempts N → more: you see both successes and failures more often, but it costs more. The paper used 8. For manual work, 3–4 is enough. - The “surprise” criterion → stricter: less noise in memory. Looser: more lessons, but a higher risk of junk. - Conditions of applicability → always demand the “when yes / when no” pair. This is the backbone of the method. - The rule for the “all failed” case → keep the ban on making things up: recommendations only from actions actually observed. - Similarity search threshold → wider: better odds of catching a conflict. Narrower: faster, but you might miss a contradiction.
Prompt Template
The paper doesn't include the prompt texts, only a description of the steps. Below is a reconstruction based on their logic. The structure (judge → inductor with four cases → consolidator) is preserved.
=== STEP 1. JUDGE (run on each attempt separately) ===
<Role>You are the judge of the agent's attempts. You don't solve the task; you evaluate how it was solved.</Role>
<Task>{task}</Task>
<Trajectory>{attempt_log}</Trajectory>
<Feedback>{check_result_or_empty}</Feedback>
Verdict: OK only if (a) the result is correct AND (b) the reasoning is correct.
Otherwise: SURPRISE.
If SURPRISE, return:
DIAGNOSIS: [what went wrong, or why the correct answer was luck]
REFLECTION: [which decision was wrong, 2–3 lines]
=== STEP 2. INDUCTOR (run once per task, if not all attempts are OK) ===
<Role>You are an experience analyst. You compare attempts on a single task and derive a transferable rule.</Role>
<Task>{task}</Task>
<Confirmed_Successes>{full_OK_trajectories}</Confirmed_Successes>
<Other_Attempts>{diagnoses_and_reflections}</Other_Attempts>
<Success_Rate>{n_successes} of {N}</Success_Rate>
Identify the case and act:
- Successes are the majority → turn the minority's mistakes into WARNINGS.
- Successes are the minority → find the DECISIONS that set the successful attempts apart.
- Even split → write down both the WINNING STRATEGY and the TRAP.
- No successes → describe only the FAILURE PATTERNS from the diagnoses. Do not suggest actions that aren't in the data.
Candidate format:
DECISION: [a decision, not a sequence of clicks]
WHEN TO APPLY: [conditions]
WHEN NOT TO APPLY: [conditions]
EVIDENCE: [what the comparison of attempts showed]
=== STEP 3. CONSOLIDATOR ===
<Role>You are the memory consolidator. You add the candidate to memory without duplicates or conflicts.</Role>
<Candidate>{candidate_from_step_2}</Candidate>
<SimilarEntries>{numbered_memory_entries}</SimilarEntries>
Rules:
1. Duplicate → discard, give the number.
2. Conflict → new entry with explicit “when yes / when no” conditions; flag the old one for deletion.
3. Do not rewrite unaffected entries.
4. Do not add anything beyond the candidate.
Return: ADD / DELETE / REASON.
What to fill in: {task} is the task statement, {attempt_log} is the agent's output or the conversation, {check_result_or_empty} is tests, a comparison to a reference answer, or your own judgment. {N} is the number of runs (3–8). {numbered_memory_entries} is a few lines on a similar topic from your lessons file (lessons.md, a section of CLAUDE.md).
🚀 Quick start: paste this into the chat:
Here is the Hippo template (judge → inductor → consolidator). Adapt it to my task: [your task and agent].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask how you check the result (what counts as success), where the memory is stored, and which mistakes have already repeated. The judge needs a “right or wrong” criterion, and the consolidator needs the format of the entries it will compare new ones against. Then it will adapt the template to your agent and memory file.
Limitations
⚠️ You need a way to verify results. The judge relies on feedback: tests, a reference answer, manual review. Without it, the judge may overrate a sloppy trajectory, and a wrong rule ends up in memory. The authors themselves name this as one cause of degradation.
⚠️ The full loop requires code. Parallel runs, similarity search, and feeding memory into context are automated with a script. In a chat you only get the manual version: run it 3 times, stitch the logs together, paste the lesson in by hand.
⚠️ Cost. N attempts per task multiply your token spend. For one-off tasks the method doesn't pay for itself: it's built for a long stream of similar tasks.
⚠️ Plain retries already go a long way. Before building memory, compare against the good old “run it a few times and take the best.” That's the honest bar for any self-learning.
⚠️ Gains on strong models are more modest. They show up on top-tier models too, but noticeably smaller than on lightweight ones. The effect depends on the website and the task type.
⚠️ If all attempts failed, there's little benefit. The inductor then has no success example and can only describe failure patterns. In the paper, this group showed the smallest gain.
⚠️ Tested only on web agents and code (SWE-bench, WebArena, Mind2Web). For writing, sales, and analytics it's a transfer by analogy. The excerpt of the paper doesn't include the full section on the number of attempts; it cuts off.
How They Tested It
The team tested the method on three benchmarks: fixing bugs in code (SWE-bench Verified, 500 tasks), web tasks (WebArena), and next-step prediction on recorded pages (Mind2Web). They used four models with frozen weights, from GPT-5.6 Sol to Qwen3.5-27B. They compared against an agent with no memory, against “just more steps” (Vanilla-IB), and against two well-known memory methods (AWM and ReasoningBank). Each task was run 8 times, and the whole experiment was repeated with three different seeds.
The most intriguing experiment is a long stream of 450 tasks. Every few tasks, they tested both “old” tasks (has the memory forgotten?) and new ones. AWM and ReasoningBank improved at first, then dropped below the no-memory agent. At task 400, Hippo scored 86% and 82% on old and new tasks. That's 24 and 22 points above the strongest baseline. Meanwhile it stored 83 memory entries versus 270 and 665. An append-only variant of Hippo (no cleanup) trailed full Hippo by 14 and 16 points. So memory cleanup does the lion's share of the work.
A surprising takeaway: simple retries buy you a lot. The no-memory agent on WebArena solves 64.3% on the first try and 73.6% under “at least one of eight.” That's a gap of 9.3 points. It's a higher bar than it looks, and the authors propose that every self-learning method be compared against it. Another takeaway: task groups where most attempts succeeded gained 23 points, groups where most failed gained 13, and groups where all failed gained 3.3. Comparing a win to a loss is more useful than dissecting failures alone. The paper also notes that in related work, replacing memory with meaningless symbols didn't always hurt success. So the value of memory depends on what's actually in it.
Adaptations and Extrapolations
🔧 Technique: drop the “automation” → audit your instructions file by hand every N tasks
No retrieval code needed. Every 10–20 tasks, paste your
CLAUDE.mdorlessons.mdinto the chat and hand it to the consolidator: “Find duplicates, contradictions, and entries without conditions of applicability. Propose merges and deletions. For every entry without a condition, add "when yes / when no".” This is a manual version of step 3 with no retriever.
Extrapolation (my idea, not in the paper): add a recording rule to the agent's system prompt. For example: “Add a new lesson to lessons.md only after a mistake, or when the result is right but the path was wrong. Every lesson: decision + conditions of use + conditions when not to use it. Before writing, check the file for duplicates or contradictions.”
Resources
- Hippo: Training-Free Agent Self-Evolution via Hippocampal Replay — Yutong Song (UC Irvine), Jiang Wu (independent researcher), Yuxuan Ren (Rice University), Tony Qin, Baoyuan Wang (Zillow Group).
- Compared against: ReasoningBank (MaTTS), Agent Workflow Memory (AWM), Vanilla-IB. Related work: Reflexion, ExpeL, Mem0, A-MEM, MemGPT.
- Benchmarks: SWE-bench Verified, SWE-bench Pro, WebArena, Mind2Web.