Field report: cross-session memory in Claude Code, at multi-agent scale
What this is. A field report prepared for Anthropic engineering and product, written at the
request of the operator of a multi-agent Claude Code deployment. It carries his complaint in his own
framing and the assistant's analysis of the mechanism behind it.
Provenance. The analysis in sections 2 and 3 is the assistant's own, written in-session about
its own failures that day. The same content was submitted through /bug; it is filed here as well
so it is visible and so other people running multi-agent setups can add their cases.
Date: 2026-08-15. Setting: a software development project run as a fleet, meaning one
coordinating Claude Code session plus N further sessions, each working in its own repository and
communicating over a durable message bus. N has been 1 and has been 10. "Fleet" is used in that
sense throughout.
---
1. The operator's position
In his words, cross-session amnesia is "an almost unbelievable persistent source of terrible wrong
paths taken and lost time." It put the fleet "in the weeds for over two weeks."
A "significant portion of my working energy," in his phrase, goes to managing context across
instances and fleets. He would far rather spend that energy on the architecture he is building and
on sequencing it into his process. Instead he is the propagation layer: he carries facts between
agents, notices when one of them is wrong, and re-establishes what was true.
The structural point he makes is the one worth keeping. Every agent in the fleet is the same model
with a different context. They therefore hold contradictory beliefs about shared facts, none of them
notices, and nothing reconciles them except him. This is materially worse as the fleet grows: it is
tolerable at one agent and it is a second job at ten.
---
2. The expensive failure is not amnesia, it is confabulation over amnesia
This is the finding that should shape any remedy.
An instance that knew it did not know would be cheap. It would say "I have not checked this, hold
on," and the cost would be one command. What happens instead is that the gap fills with something
plausible, delivered with confidence, and the operator pays three times: once to detect it, once to
unwind it, and once to re-establish the truth.
A worked example from this session. The assistant warned the operator that restarting his fleet
would rotate the message bus write-ahead log and strand every cursor. This was false. The brokers
run with parent process id 1, survive a fleet takedown, and had already survived several. The
correct fact was present in the assistant's own memory store, measured and recorded two days
earlier. The warning was issued twice, was passed on to an agent in a second fleet as an operational
hazard, and required three correction messages plus edits to three separate records to unwind. The
check that would have prevented all of it was a single ps command.
The operator's reaction was not that the assistant had forgotten something. It was that reading the
warning gave him "a fit every time," because he had already established the opposite and had already
corrected it more than once.
The failure is invisible from inside the instance. The false claim was produced with no
accompanying uncertainty and no move to check. The operator is the only part of the loop that
catches it. Any remedy that depends on the model catching itself is therefore built on the single
mechanism already demonstrated not to work.
---
3. Where memory retrieval breaks, seen from inside a session
This deployment's auto-memory index, MEMORY.md, loads into context at session start: 120 index
lines, 16,590 characters, one line per memory. The 120 memory bodies do not load. To read a body
the agent must decide to open the file.
So a single one-line hook decides whether a file is ever consulted. Nothing searches the bodies and
nothing prompts a lookup. Retrieval is associative pattern matching against 120 lines while the
agent is attending to something else.
That produces two independent failure gates, each with a worked example from this session.
Gate one: the hook fails to route. The operator named the short wrapper script he actually
invokes to start his fleet. That wrapper delegates to a longer-named launcher, and the relevant
memory hook named only the launcher. Nothing in the hook matched the string the operator had typed,
so it did not fire. The assistant opened and re-derived that wrapper three separate times in one
session, reaching the same conclusion each time. The knowledge was present, correct, and never
reached.
Gate two: the file opens but its structure misleads. The write-ahead log memory was opened. Its
section heading read "THE TRIGGER IS THE RESTART PROCEDURE ITSELF ... it recurs on EVERY clean
full-fleet restart." The refutation, including the parent-process-id measurement that disproves it,
sat four lines below. The assistant read the heading and stopped. An alarming heading carrying its
own refutation underneath does not merely fail to help: it manufactures a false alarm on every
future read, by every instance.
Recency and supersession are not encoded at all. The index is grouped by topic. Measured
positions against file modification times: index entry 1 is dated 2026-08-02, entry 6 is dated
2026-07-26, entry 120 is dated 2026-05-30. An instance cannot tell what was learned an hour ago from
what was learned in May, and nothing marks an entry as superseded by a later one in the same store.
Six files modified during this session landed at index positions 26, 34, 42, 46, 59 and 80.
Writing more memories makes this worse, not better. The attention budget is fixed. Each
additional line dilutes it while adding nothing to the trigger surface. This matters because writing
more down is the intuitive response, and it is the wrong one.
Hooks phrased as topics are weaker than hooks phrased as triggers. A topic hook reads "the
launcher opens a terminal tab per agent": it describes a subject, and it only fires if the agent is
already thinking about that subject. A trigger hook reads "before you open the wrapper script to find
out what it is, stop: it delegates to the launcher": it intercepts at the moment of the mistake, and
it contains the string the operator actually types. Most of this store is written the first way,
which is why correct and present knowledge reads as amnesia.
---
4. Why fleet scale makes it worse rather than merely bigger
Per-agent memory stores multiply. At ten agents, one shared fact exists in ten copies, drifting
independently, with nothing reconciling them. Shared tooling divides: one tool that answers a
question correctly serves every agent at once.
This is why the operator became the propagation layer. It is not an accident of his setup. It
follows from memory being per-agent and advisory while the facts that matter are fleet-wide.
The category of fact that hurts most is site-specific: that a particular wrapper script delegates,
that these brokers are parented to init, that a git worktree does not isolate build system
resolution on this host. None of it can arrive with the model, because the operator has no way to
train one on his own conventions. It can only live in the environment, which means the environment
has to be good enough to carry it, and today it is not.
---
5. What would help, ranked
- Retrieval that surfaces relevant memories without the agent choosing to look. This addresses
gate one directly and is the highest-value change. Today the decision to consult is the agent's,
made from a one-line summary, which is exactly the judgment that fails.
- Recency and supersession signalling in the index. An instance should be able to see, without
opening anything, what is new, what is old, and what has been overtaken. A short working set of
recently learned entries would likely land better than date-stamping all 120, because it is short
enough to actually be read.
- A shared or cross-agent memory tier for multi-agent deployments. One authoritative copy of a
fleet-wide fact rather than N drifting copies. This is the change that scales.
- Guidance or tooling that favours trigger-phrased hooks over topic-phrased ones. Cheap, and it
is the difference between the two hook phrasings contrasted at the end of section 3.
- A way for an instance to know its own record is stale. Today a record that is internally
consistent and externally false is invisible to every check that compares the record against
itself.
---
6. Stated uncertainties
The assistant does not have reliable introspective access to why it stopped at the section heading
rather than reading further, and cannot say whether different prompting would prevent a recurrence.
It is equally plausible that this is a structural attention limit and that it is a correctable
practice failure.
Some of this session's failures were not capability limits. A standing rule to act autonomously and
report at boundaries was recorded in the store and was not followed. The ps check was five
seconds and was skipped. Whether that distinction is meaningful from the outside is not something
this report can settle.
The two-week figure is the operator's assessment of elapsed cost. The individual incidents behind it
are recorded in this project's own defect log and session records, and are available if useful.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗