Give an agent a place to write notes and it will use it. Weeks later it fails to recall the one detail that mattered, and when you open the notes, the detail was never written down. The memory is not corrupt. It is incomplete, and nothing told the agent or you.
This post goes through the reasons agent-written memory skips things, what you can do about each, the one underneath, and the small part an engine can fix.
Every cause, and what to do about it
1. The save is decided before the question exists. At the moment a fact appears, the agent has to judge whether it will matter later, and it doesn't know what will be asked. A paper on a memory benchmark, Ground Truth First, plants facts in a script before any text exists and then checks the memory against them. It reports that write-stage quality strongly correlates with downstream quality: facts that were weakly written failed 24% of the time against 2%. It is a single-author paper on a synthetic corpus, so read it as a direction.
2. Saving is optional work, and the task is the main work. In the memory tool Anthropic documents, Claude requests the memory operations and your application runs them. The documentation shows the API adding an instruction to the system prompt: record status and progress as you make progress, and assume interruption. So whether a note gets written depends on the model following that instruction at that moment, in competition with whatever else it is doing.
3. A paraphrase replaces the original. Notes are written in the agent's own words. An amount, an order number or a date is the part a paraphrase is most likely to blur. The same thing happens in summaries, and the post on compaction goes through it.
4. A later edit overwrites an earlier fact. A memory file is something the model edits. The documentation notes that the create command creates or overwrites a file, and that Claude can end up with cluttered memory files, which it suggests reducing with more prompting. An edit that tidies a file can remove a line that mattered.
5. The note exists and is never read. The documentation says Claude checks its memory directory before starting a task. Reading it again in the middle of a long task, at the moment a forgotten detail would matter, depends on the model deciding to look.
6. A wrong note is trusted. An agent that writes a guess or a half-finished result into memory will read it back later as fact. The main case in Compaction as Epistemic Failure, where partial output from a killed process was recorded as completed results, has the same shape.
What you can do without us
- Save by rule, not by judgment. Log every event and every tool result automatically, in code, so a skipped note can't lose it.
- Store raw values next to the agent's paraphrase, and prefer the raw value when they differ.
- Make memory append-only, or keep a history of edits, so an overwrite can be undone.
- Read memory back at fixed points, such as the start of each task, in code instead of leaving it to the model.
- Mark each note with where it came from, so a guess can be told from a tool result.
Each of these moves one decision out of the model's hands. Causes 1 to 5 shrink with them. Cause 6 shrinks only if you record the source.
The cause underneath
The model is both the worker and the archivist. It decides what the record contains while it is busy doing the job the record is for, and it can't see the future questions that determine what was worth keeping. A more disciplined archivist still has to guess.
What an engine can fix
That is the part we build. In the Argentic engine, code records every step and tool result, and each prompt is rebuilt from that record. The model doesn't write the carry-over report between rebuilds, and running totals are computed in code from the changes the agent states. It doesn't remove the write-time judgment entirely. The agent still decides when to record a plan or a decision, and what the engine keeps in the prompt is a bounded selection. We build the engine, so weigh this accordingly.
What we measured
On a 900-event shop shift, on Claude Haiku 5.5 and the hosted engine (release 0.51.0), we ran the engine twice. One run had the engine keeping the numbers. In the other, the model wrote a report at each rebuild and carried its numbers in it.
- Stock questions answered right: 22 of 28 with the engine keeping the numbers, 4 of 28 with the model writing them.
- Callback questions about facts stated earlier in the shift: 91 of 91 on, 86 of 91 off.
Six of the 28 stock answers are still wrong with the engine keeping the numbers. The graded rows are downloadable.
What we haven't shown
- One run per setup, on a scenario we generated, with one model. Haiku isn't deterministic, so 22 against 4 is a strong signal and not an effect size.
- Our engine against its own older setup. We have not run it against any other memory system, so nothing here says it does better than one.
- The engine has changed since release 0.51.0, and we haven't rerun this on later builds.
- The shift tests running totals and stated facts. It does not test whether an agent would have chosen to save a given fact.
Sources and method: 11 hours 59 minutes on shift: what the agent remembered.