AI Agent Repeating the Same Mistake? Check Its Saved Notes First

When an AI agent repeats a mistake after you have changed the prompt, one cause the prompt cannot reach is a wrong note the agent saved earlier and still trusts. Rule that out first: open what the agent saved and compare it to the source record, and if several agents write to one shared notes file, give each record a single writer.

The notes are part of the system: an agent that works across sessions, or splits a batch of contracts, quotes or tickets with other agents, writes down what it has learned and reads it back later. Those notes sit beside your instruction when the agent decides what to do next. If a note says a quote is approved or a step is done, the agent acts on that. A better-worded request does not change what the note says.

A saved note can outvote your prompt

In The components of agent memory, published on 6 November 2026, Anthropic describes an agent playing Pokémon Red, a game rather than a business task, that saved a wrong note marking one part of the game as done. In the run with the uncorrected note, it dropped back onto an earlier route three times. Afterwards, a review pass checked the note against the session transcript, caught its error and rewrote it. One run of one game shows the mechanism, not how often it happens.

The same article warns that an incorrect note in always-loaded memory can be carried into every session, and Xiong et al., in a study of how memory management affects LLM agents, describe error propagation: inaccuracies in past experience that compound and degrade later performance.

Picture a hypothetical business version. An agent comparing supplier quotes saved “Supplier B: net 30” when the quote says net 60. Every later step that reads the note works from the wrong terms. Adding “check payment terms carefully” to the prompt does little, because the agent believes it already has the payment terms. A missing term leaves a gap the agent may notice and go back for. A wrong one hands it a confident answer to act on.

Check what it saved before you reword the prompt

Run this check every time a mistake repeats, before you touch the instruction:

1. Find where the agent writes. A memory file, a notes folder, a shared document, a table, a wiki. If nobody on the team can say where it writes, that is your first finding, and the next fix is to make that place visible.
2. Pull the notes for the items that went wrong. Skip the rest of the store. If the mistake is on payment dates, pull the records for the suppliers or invoices involved.
3. Lay each saved note beside its source. The quote, the contract, the ticket. Compare only the terms that must be exact: names, prices, payment terms, dates, status.
4. Sort every term into one of four. Exact (copied correctly), summarised (meaning blurred, such as “about 2 weeks” for a stated date), wrong, or missing.
5. Fix the wrong ones first, in the notes. Correct or delete the record, then rerun the job. Wrong terms come first because the agent acts on them; summarised and missing terms come next.
6. Only then change the instruction. If the mistake repeats with correct notes, the prompt or the instruction file really is the problem.

Step 6 is where vendor advice comes in. The Claude Code documentation, checked on 9 November 2026, lists “Claude makes the same mistake a second time” as a reason to add to the project instruction file. That advice stands; the check goes in front of it. The same documentation says that when two instructions contradict each other, Claude may pick one arbitrarily. A new instruction added on top of a wrong note risks a similar standoff between what you said and what the agent saved. That last point is an inference; the documentation does not test it.

Here is the record the check produces, filled in once for the hypothetical quote batch. The numbers are made up for illustration: six supplier quotes, four exact terms each (unit price, payment terms, delivery date, validity date).

Eighteen of the 24 terms survived exactly and 6 did not. Of those 6, only one is wrong, and it sits on Quote 3’s payment terms: the most likely explanation for a payment mistake that keeps coming back, and the one a reworded prompt would not touch. Copy the table and replace the rows with your own items and the terms that must be exact for them.

Give each record one writer and quote the exact terms

If the check keeps finding blurred or lost terms, the layout of the notes is the next suspect, especially when several agents write to the same place.

The Anthropic article reports one such test, a simulated company acquisition from its LAB benchmark. Several agents wrote to a shared table of contract terms at the same time, and a graded brief generated from the resulting wiki included only 41 of the 57 facts (72%): terms were summarised poorly, and some were missing because agents had overwritten one another’s work. After the change, each contract got its own page, written by a single agent that quoted the terms word for word, and 100% of the criteria could be met.

The article gives no run count for that result, and several things changed together: the page per contract, the single writer, the verbatim terms, and instructions Claude rewrote after reflecting on its failures, because the original instructions never said the contract terms mattered most. You cannot credit the layout alone, so adopt the bundle:

• One record per item. One page for each contract, supplier, quote or ticket. Not one big table that every agent updates.
• One writer per record. During a job, only the agent that owns a record edits it. Another agent that has something to add writes to its own record or passes it to the owner. Two writers on one record is how terms get overwritten.
• Exact terms quoted, not paraphrased. Names, prices, payment terms and dates are copied from the source, with where they came from (clause, page, line). The agent’s own summary goes below them, labelled as a summary.
• A purpose line at the top. One sentence saying what the notes feed and what matters most. More on this in the next section.

A record laid out this way looks like this (hypothetical):

Record: Supplier quote, Supplier B
Owner: agent 2 (the only agent that edits this record)
These notes feed the supplier comparison. Prices, payment terms and dates are the priority.

Exact terms, copied from the quote:
- Unit price: "..." (page 1, line 4)
- Payment terms: "..." (page 2, clause 3)
- Delivery date: "..." (page 1, line 9)
- Valid until: "..." (page 2, footer)

Summary (agent's words):

Which information may be stored at all, and who can correct it, is a separate governance question, covered in What Your AI Is Allowed to Remember, and Who Can Correct It. This layout is about whether the facts survive the job.

Tell the agents what the notes are for, not how to write them

The tempting next move is a rulebook: always save X, never save Y, summarise in this format. In Anthropic’s tests that backfired: on its CL-Bench task, a rule to record only failures cost two of its stronger models much of the gain memory had given them, and the article concludes that, for those models, freedom to judge what matters beat fixed rules. Anthropic recommends telling the model what memory is for, not how to use it. The contract fix came from the same direction. These are tests on Anthropic’s own models and benchmarks, so treat them as the best available guide without assuming they hold for every agent.

In practice that means two layers and nothing more. The structure is yours to set (one record, one writer, exact terms quoted), and so is the purpose line (“these pages feed the acquisition brief; contract terms are the priority”). What the agent chooses to note beyond that, leave to the agent.

Keep the always-loaded layer short as well. The Claude Code documentation, checked on 9 November 2026, advises keeping each instruction file under 200 lines because longer files reduce adherence, and reviewing them periodically for outdated or conflicting instructions. That is unmeasured vendor guidance for one product, but it points the same way: every rule you add after a repeated mistake makes the file longer and the next contradiction more likely.

Let a clean-up pass propose, never overwrite

Notes that live across many sessions decay. Anthropic’s Dreams documentation, checked on 9 November 2026, says a memory store accumulates duplicates, contradictions and stale entries. Dreams, a research-preview feature of Claude Managed Agents billed at standard token rates, reads the store alongside past session transcripts and produces a new, reorganized store, leaving the input untouched so the output can be reviewed and then used or discarded.

Copy that shape for any clean-up, whether it is a product feature or a script your team runs:

• The pass writes a new version of the notes. The old one stays untouched until the new one is accepted.
• The pass works against the source (the transcripts, the contracts, the tickets), not only against the old notes. The Pokémon error was caught because the review checked the note against the transcript; a pass that only rereads the notes has nothing to catch an error against.
• Someone compares the new version to the source before it replaces the old one. The table above is that comparison: run it on a sample of records, and fix or reject the new version if a wrong term appears.

Treat any automatic clean-up, Dreams included, as a proposal until that review is done.

When one agent is the better fix

One writer per record is the narrow fix. The wider one is not to run parallel writers at all. Cognition argues in Don’t Build Multi-Agents (Walden Yan, 2025) that parallel subagents might give conflicting responses, and that the simplest way to follow its principles is a single-threaded linear agent. That is a vendor’s argument with no test behind it. Separately, a position paper by Yu et al. on multi-agent memory calls consistency of memory across agents the most pressing open challenge. Treat shared multi-agent notes as a design problem that is still open.

The decision rule follows from how your items relate. If each item can be judged on its own terms, as in a stack of supplier quotes or a backlog of separate tickets, split the batch by record and give each record one writer. If items depend on each other, so that a finding in contract 3 changes what matters in contract 7, give the job to one agent with the full context and accept that the batch runs in sequence.