Team Memory Fails Everywhere at Once

Practitioner writing on runbooks, wikis, postmortems and internal Q&A tools keeps arriving at the same distinction. A knowledge system that is a separate destination rots. One that is embedded in the work survives. Most of that writing comes from incident-management blogs and documentation guides, not controlled studies, so it is a consistent observation, not a measured effect.

A wiki is a destination. Writing to it means stopping work, switching context and finding the right page. Reading it means remembering that the page exists and choosing to go and look. Each step is a small cost. Together they are enough to kill the habit: pages get written once and then orphaned. And nothing turns red when a page goes stale. A page reviewed last week and a page untouched for three years render identically, in the same font, at the same kind of URL.

The knowledge practices that do last have three things in common.

• An owner. A runbook that somebody owns gets updated when the system changes, because a named person answers for it. An unowned runbook decays at whatever rate the system changes.
• A place inside the work. The runbook that survives is the one linked from the alert, so it opens in the same place the incident is already being handled. Nobody has to remember it exists.
• A ritual that routes attention back. Something recurring, and usually social, keeps sending people to the document after it was written.

Postmortem culture is held up by rituals, not by storage

The best-documented case of the third property is the postmortem practice in chapter 15 of Google's Site Reliability Engineering book, "Postmortem Culture: Learning from Failure". The chapter is blunt that the culture does not maintain itself: introducing it "requires continuous cultivation and reinforcement." What does the reinforcing is a list of social activities.

• A postmortem of the month goes out in a newsletter to the whole organization.
• Teams run postmortem reading clubs, where an interesting incident is brought to the table for an open discussion with people who were involved and people who were not. The chapter adds that the postmortem being reviewed is often "months or years old".
• New SREs go through the Wheel of Misfortune, in which "a previous postmortem is reenacted with a cast of engineers playing roles as laid out in the postmortem."
• Senior management takes part in reviews, and the chapter asks that writing good postmortems be "a rewarded and celebrated practice."

None of this is about where the documents live. The chapter mentions in passing that its postmortems are Google Docs with an in-house template, and moves on. What keeps a postmortem from becoming one more orphaned page is that people keep getting sent back to read it, years after the incident.

There is an older account of how groups remember at all, from social psychology. Daniel Wegner's theory of transactive memory, set out in a 1987 chapter, holds that a group does not keep one shared store of facts. Each member holds some facts, plus a sense of who holds the rest. Wegner's own summary of the idea is that people need not remember everything a group needs to know if each "merely stores in memory information about who is likely to have a particular item," and that this "capacity for remembering who knows what is the key to transactive memory."

The chapter is specific about how that directory routes work. "Known experts in a domain are usually held responsible for the encoding, storage, and retrieval of any new information encountered in that domain." Questions about the domain "are typically directed to this person by default," and other members "contribute to this centralization of information by delivering new information to the appropriate expert."

Read with team knowledge in mind, that routing has a side effect: the person a question goes to is also the check on the answer. Ask the build expert which JDK the build needs and you get today's answer, not the one written down two upgrades ago. If the question itself carries a stale assumption, the expert hears it and corrects it. That reading is an interpretation of the theory, not something the chapter tests. The chapter does name what happens when the routing is bypassed, in one sentence: "When an organizational system is built that channels information away from experts, for instance, things may be forgotten."

A shared memory store that answers a question directly, without routing it to anybody, is a system that channels information away from experts. It can still be the better system overall. But the check that came free with routing is gone, and it has to be rebuilt on purpose.

Agent memory removes both of the frictions that kill wikis.

Write friction drops close to zero. An agent that discovers a build requirement while fixing an unrelated bug can record it in the same session, through a memory tool it already has, as a side effect of the task. Nobody opens a wiki.

Read friction drops close to zero. A harness can deliver a stored note at the point it becomes relevant: when a prompt mentions deploying, or just before the agent runs a build command. Agent harnesses expose hooks at points like these, and a memory system can use them to put a note into the model's context window without the model asking.

Put a shared instance behind both and the note one developer's agent stores can be recalled by every other developer's agent. vectr, an open-source code-search and agent-memory tool I maintain, shipped this as team mode in its 1.1.0 release. Its changelog says that on the central instance "a note one connected agent stores, every other can recall," and that "the client label attributes notes (author) and audit-log lines." This is the property knowledge management has always wanted. Something is learned once, by whoever happened to hit the problem, and used everywhere, at the moment it matters.

But the filters that limited the damage from wrong knowledge were attached to the frictions. Remove a friction and its filter goes with it, unless something else is built to do the same job.

A wrong wiki edit gets read occasionally, by one person at a time, over weeks. A wrong shared note gets delivered to every agent session that hits the matching situation, and on an active team that can mean several sessions before lunch. There is no slow decay curve and no local containment. The interval between an error being recorded and many people acting on it can shrink from weeks to hours.

A person reading a wiki page sees its age, its author, its edit history, and formatting that looks like it was written for an older version of everything. An agent receiving a delivered note sees a sentence in its context window. Unless the memory system encodes age and provenance explicitly, and puts them in the text the agent actually reads, the cues that make a person pause do not exist.

Agents are not uniformly credulous

That does not mean agents believe everything. In vectr's injection-utility benchmark, an agent that received a note on the turn where it mattered, with the full note body and no sceptical framing around it, still declined to act on it, "explicitly citing that the claim did not come from the user and had no corroboration in the repo." In another run, over a second delivery channel, an agent applied the fix a note described while still declining another, uncorroborated instruction in the same note. The benchmark's README reads the remaining failure as one that "follows the uncorroborable content, not the delivery channel."

Agents Over-Trust Instructions and Under-Trust Corrections describes the other half of the picture. A note that contradicts what a model has seen thousands of times in training has to displace that prior, and it often loses. A claim about something the model has no prior on lands, in that article's image, on an empty shelf, and stays there because nothing pushes it off.

Team memory is mostly made of empty-shelf facts

Team memory is mostly the second kind of note: team-local facts with no prior at all. Which service owns the queue, which JDK the build needs, which staging host takes deploys this week: nothing in a model's training argues with a note like that, so it is likely to be accepted. That benchmark result is a reason not to overstate this. The declined note was the only source of truth in its workspace too, and it was declined because nothing corroborated it. Whether team-local facts really are adopted more readily than notes that fight a default is a prediction (the third one in Section 13), not a finding.

Acting on a note produces its own corroboration

That scepticism is weaker than it looks, because of one mechanism. An agent that wants corroboration before trusting a note can often get it by following the note. Told the build needs JDK 21, it installs 21 and runs the build. The build passes. That is the corroboration it was looking for, and it is worth nothing, because a newer JDK builds most code written for an older one: the build would have passed if the note were wrong. Scepticism that asks "does the evidence agree with the note?" is satisfied by evidence that would have agreed either way.

Suppose one agent records "the build requires JDK 21", and it is wrong. The services run on JDK 17, a version fixed by the CI image and the production hosts and pinned nowhere in the repository, and the first agent's machine just happened to have 21 installed when it saw the build work. A second agent, working under that note, sets up JDK 21, the build passes, and it records "confirmed: build passes on JDK 21". A third does the same. The store now holds three notes from three authors, all in agreement. Meanwhile any agent that believes the note is free to reach for a language feature or library method that 17 lacks, and that code builds on every laptop and fails on the CI runners.

They are not three observations. They are one observation and two consequences of it. Richards Heuer's Psychology of Intelligence Analysis, written for CIA analysts, describes the trap in one sentence: "Information may be consistent only because it is highly correlated or redundant, in which case many related reports may be no more informative than a single report."

Economics has a model of what happens next. Bikhchandani, Hirshleifer and Welch define an informational cascade as the point at which "it is optimal for an individual, having observed the actions of those ahead of him, to follow the behavior of the preceding individual without regard to his own information." After that point the agreement stops carrying information: "the 'depth' of an informational cascade need not rise with the number of adopters; once a cascade has started, further adoptions are uninformative."

The fit with agents is close, not exact, and the gap matters for the fix. People in the cascade model ignore their own evidence. The second agent here does not ignore anything. It runs the build and reports what it saw. The trouble is that what it saw cannot tell the two hypotheses apart, and it only looked where the note pointed. That is nearer to Heuer's correlated reports than to a pure cascade. Both diagnoses lead to the same rule, though: a confirmation counts only if it could have come out the other way.

Independence has to be defined by lineage

Any rule that promotes a shared note once enough distinct authors agree is fooled by this. Three authors are not three sources if two of them had the first note in context when they made their observation. The workable definition of independence is lineage: a confirming observation counts as independent only if the session that made it had not been given the original note. There is a stricter condition too, that the observation discriminates, and no store can check that mechanically. Lineage it can check.

The store has to compute lineage itself. It cannot rely on the writer to declare it. The production memory service that Margalit and colleagues evaluate records lineage the declared way: each write carries a derived_from field naming its parent, and their harness walked 50 four-step derivation chains back to the root with the correct writer identity at every step. That works when the writer knows its note is derived. The second agent in the JDK case does not think of its note as derived. It thinks it checked. Only the memory system knows what it put into that session. A delivery log turns "had the original in context" from a judgement call into a database join.

Two details decide whether the join is right. The log has to cover both channels: notes the harness pushed into a session, and notes the agent pulled with a recall call. And lineage is transitive. A session that received only agent B's "confirmed" note depends on the original as much as one that received the original itself, so the join runs over the original and every note written by a session that had any of them delivered. Treating "delivered" as "in context" overcounts dependence a little, since a long session can lose a note to compaction before it acts. For a promotion gate, overcounting dependence is the safe direction to err in.

Lineage from a delivery log is a lower bound on dependence, not the whole of it. A developer can paste a note into a prompt by hand, which no log sees. Two agents can share a cause without sharing a note: if every machine on the team was built from the same image with JDK 21 preinstalled, independent sessions will independently "confirm" the same wrong requirement. Lineage catches the dependence the system created. It cannot see the dependence the environment created, which is one more reason to prefer observations that discriminate.

Two developers' agents record different JDK requirements a month apart. Both come from real observations; the requirement changed in between. A store that keeps both serves a contradiction, and the next agent gets two confident answers with nothing to say which one is current. A store that silently keeps the latest throws away the history that would explain the change, and it is only right when the later note is the one that reflects the change. If the later note is the mistaken one, latest-wins promotes the mistake.

Margalit and colleagues name this failure contradiction persistence, defined as "conflicting memories coexist without resolution," and their service resolves it by temporal supersession under policy rules. Their live evaluation turned up a sharper problem on the write path. The contradiction detector itself worked: when both conflicting writes were admitted, it superseded correctly in every case, 90 of 90. But a synchronous near-duplicate gate ran first and rejected writes whose embedding was too close to an existing note, and, in their words, "a contradiction is precisely a near-duplicate with a different assertive object."

"The build requires JDK 17" and "the build requires JDK 21" differ by two characters. The step built to keep the store tidy was rejecting the very writes the contradiction detector existed to catch, before the detector ever saw them.

Telling a contradiction from a rewording also needs the claim in a structured form, a subject, a property and a value, so that "same subject and property, different value" can be recognised at all. Margalit's detector works on claims in that shape. Free-text notes need an extraction step first, and the extraction is one more place for an error to enter.

Before vectr's team mode shipped, seven agents built and reviewed a command-line tool from scratch while coordinating only through one shared memory instance, with no shared chat. A contract note carried the interface the three coder agents had to build against, and it stated an assumption: byte-identical copies of the transcribed contract could not produce merge conflicts. The three coders worked concurrently, each in its own git worktree. The transcribed bodies did match. But each coder, in good faith, added its own differently worded module docstring on top of the contract, and at merge time those additions collided as textual merge conflicts that the note had said were impossible.

The note was wrong about one detail, and every agent that received it inherited the mistake at the same time. The lesson was recorded for the next run: a contract note has to forbid additions, docstrings included. The full account is in Vectr 1.1.0: Team Mode and the Seven-Agent Test.

That failure was cheap because a merge step caught it. Git refused to combine the branches until the conflicts were resolved, so the wrong assumption surfaced as a stop, not as shipped behaviour. Operational notes about builds, hosts and deploy order rarely come with a merge step. The wrong JDK note is acted on, never merged, and the first thing to object to it is a red CI run hours later, or a failed deploy.

The human practices that survived did so through owners, embedding and rituals. Agent memory already has the embedding; it is the whole point. The owners and the rituals have to be designed back in, and they have to work at the speed of the new failure. A check that takes a week to fire is no use against an error that spreads in an afternoon.

Some of these checks exist in vectr today, confirmed against its public changelog. The rest are design recommendations.

A repository-scoped note already has a reviewer

A note scoped to one repository and one team sits inside the same trust boundary as the code review that already governs that repository. If it is wrong, the people it misleads are the people who can see the code it describes, and they are the ones best placed to notice. It can propagate with no extra gate. A note that will reach other teams, or the whole organization, should need one of two things before it travels: explicit human promotion, or corroboration that is independent by lineage rather than by author count. The size of the gate follows the blast radius.

Three recent papers on shared memory for multi-agent systems all organise it in scoped tiers. Rezazadeh and colleagues separate private memory, "visible only to their originating user," from selectively shared memory, under access rules that change over time. Margalit and colleagues use four scopes in their production service: agent-local, team-shared, tenant-global and restricted. Cuadros and colleagues frame the decision about which memories become shared institutional state as a selection regime, and insist the regimes "are not a ranking but a design choice over target properties." They place human ratification where the targets are hard to measure, saying it "is useful when target properties include judgment quality, provenance fidelity, institutional coherence, and role preservation," and their own table lists its failure modes as bottleneck and operator bias.

That last point is the argument for scaling the gate instead of gating everything. A rule that every shared note needs a person's approval would rebuild the friction that killed the wiki, and a review queue that long tends to get rubber-stamped. Scaling the gate keeps the person for the notes that can do the most damage and lets the rest move at delivery speed.

The trust machinery for one user's memory is the subject of Agent Memory Needs a Trust Ladder: provenance classes, one-step promotion, and a top rung no agent can award itself. vectr ships that ladder. Its 1.3.0 release added a promotion tool that raises a reviewed, auto-captured note's trust class one step, auto to agent, while promotion to human "is reserved for user-side surfaces." At team scope the ladder needs a second axis. The question is no longer only who vouched for a note, but how far it may travel before anyone has.

Give every shared note an owner and a provenance

Who recorded it, in which session, from what observation. When a note turns out to be wrong, there is then somebody to ask, which puts back the transactive-memory check: the question goes to a person who can answer it. vectr's team mode records the first part already, through an optional label set on each connected client that attributes every note it writes to that author. The part most stores drop is the observation itself, the command that was run and what it printed. It decides whether a later confirmation discriminated, and it costs a few hundred bytes per note.

Tie staleness to the environment, not the calendar

Documentation rots because nothing turns red. A note anchored to the file or configuration it describes can be flagged when that file changes, which supplies the missing failing test for the price of one hash comparison. vectr does this. Each anchor stores a hash of the file's content at write time, staleness "is re-derived from live hashes on every check," and a drifted anchor on an operational note renders as "changed since" with a request to verify, "rather than asserting the note is wrong."

The hash has two limits. It is computed over the file's bytes, so a reformatted file drifts exactly as much as a rewritten one: the flag says the file changed, not that the claim did. And many team-local facts have no single file behind them. "Staging deploys go to host B this week" is anchored to nothing in the repository. For notes like that, a calendar expiry is the fallback, and Agent Memory Expiry Is a State, Not a Delete explains why expiry should hide a note rather than erase it.

Make contradiction an event

When a new note conflicts with an existing one from a different author, show both, with their dates and the observations behind them, to whoever recalls either, and route the conflict to a person instead of resolving it silently. The Margalit result fixes where this has to sit: before any near-duplicate gate, or the gate eats the conflicts. Authorship decides the routing. A contradiction from the same author is usually an update, and latest-wins is probably fine. A contradiction between authors means two observations disagree, and that is the case where somebody needs to look.

Watch propagation speed

An unpromoted note that is suddenly being delivered across an unusual number of sessions or repositories in a short window is the signature of the fast failure. A deterministic threshold can hold it for review without any model judging what the note says: after N deliveries within an hour, an unreviewed note stops being delivered until a person looks, with N set from the team's normal delivery rate for a new note rather than picked once and forgotten. The rule should stay dumb. A model asked to judge the content would be one more reader with no prior on a team-local fact.

The threshold makes no claim that the note is wrong. It is a circuit breaker on exposure, the D × s × m × a × T term from Section 04, capping how many sessions can act on an unreviewed claim. It has a cost: it also holds useful notes, and on a busy team the review queue has to be fast, or the breaker turns into the old write friction under a new name.

Let retractions travel as fast as errors

A corrected wiki page reaches its next reader. It never reaches the people who read the wrong version last week. A shared memory with a delivery log can do better than any wiki did: when a note is revoked, a retraction can be delivered to exactly the sessions that received it, rather than the note being deleted in silence. A silent delete protects only future sessions. Every session that already acted on the note keeps whatever it built on top of it.

Most of those sessions will have ended by the time anyone revokes the note, so "deliver to the session" really means "reach what the session left behind". It means two things: the notes it wrote, which lineage identifies and which should be flagged with the original, and the developer who ran it, who can be sent the list of affected sessions and the commits they produced. A retraction that reaches only live sessions misses most of the damage.

vectr's revocation, shipped in 1.5.0, already keeps a revoked note and shows future recalls a "previously believed" framing in place of the original content. What it does not do is reach back to sessions that received the note before it was revoked; that is the part that needs the delivery log. Should a Correction Repeat the Mistake? covers what the retraction itself should say. Public health calls the pattern contact tracing: the correction follows the path the error took.

The cascade model offers some encouragement. Bikhchandani and colleagues found cascades fragile: "the arrival of a little information or the mere possibility of a value change (even if the change does not actually occur) can shatter an informational cascade." A retraction is a little information. The difficulty was never its size. It is getting the retraction to the sessions inside the cascade, and only a delivery log knows which sessions those are. Retractions can be wrong as well, so the revocation has to be reversible, the argument of Reinstatement Is the Missing Primitive.

The durable human systems were held up by people routing attention back to them: reading clubs, re-enactments, a leader pointing at a good postmortem in front of the company. Team memory has one advantage no wiki had. It can count. It knows which notes were delivered, how often, and to whom. With more instrumentation it can estimate which deliveries changed what an agent did, a measurement that is harder than it looks for the reasons in Agent Memory Fails in Three Places and Gets Measured as One.

A short weekly digest that says a shared note saved someone an hour, or that a note sat behind a bad deploy, gives a team a reason to care about its notes and a reason to prune them. The reading club has a direct analogue: once a week, review the most-delivered notes that nobody has promoted. They are the notes with the most reach and the least scrutiny, which is where a reading club's hour does the most good. Of all these checks it is the one most likely to be skipped, because nobody can ship it in a release.

Three claims about shared agent memory can be checked against a team's own logs. None has been measured yet.

Prediction 1: exposure. On a team sharing agent memory, the number of distinct sessions that act on a wrong note before it is corrected will be much larger than the number of people who act on a wrong wiki edit before it is fixed, and the interval will be hours rather than weeks. Measurement: for every revoked note, the number of sessions it was delivered to before revocation, and the time from write to revocation. Deliveries are an upper bound on the sessions that acted; narrowing it to actions needs the same per-session judgement as Prediction 3.

Prediction 2: false corroboration. A promotion rule based on author count will promote a meaningful fraction of notes whose confirmations were derived from the original. Measurement: for every promoted note, join each confirming session against the delivery log and report the share of confirmations whose session had received the original.

Prediction 3: the least-checked notes spread furthest. Notes about team-local facts will be acted on at a higher rate than notes that contradict common practice. Measurement: action rate per delivered note, split by whether the note's claim contradicts a widely held default. This is the one most likely to fail. The benchmark in Section 05 saw an uncorroborated note declined even where it was the only source of truth, and if that holds broadly, team-local facts are protected by the same scepticism that protects defaults, at least until acting on them produces agreeable evidence.

• Lunney, J., Lueder, S. Postmortem Culture: Learning from Failure. Chapter 15 of Beyer, B., Jones, C., Petoff, J., Murphy, N. R. (eds.), Site Reliability Engineering, O'Reilly, 2016. The postmortem of the month, reading clubs, the Wheel of Misfortune, senior management's participation, and the "continuous cultivation and reinforcement" the culture requires.
• Wegner, D. M. Transactive Memory: A Contemporary Analysis of the Group Mind. In Mullen, B., Goethals, G. R. (eds.), Theories of Group Behavior, pp. 185-208. Springer, 1987. doi:10.1007/978-1-4612-4634-3_9. Experts held responsible for a domain, questions routed to them by default, and systems that channel information away from experts. Wegner's own page lists the chapter under 1986.
• Wegner, D. M. Transactive Memory, faculty page, Harvard University. The one-paragraph summary of remembering who knows what.
• Bikhchandani, S., Hirshleifer, D., Welch, I. A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades. Journal of Political Economy 100(5):992-1026, 1992. doi:10.1086/261849. The definition of an informational cascade, uninformative later adoptions, and the fragility of cascades to a little new information.
• Heuer, R. J. Psychology of Intelligence Analysis. Center for the Study of Intelligence, CIA, 1999. Chapter 10, "Biases in Evaluation of Evidence", on consistency produced by correlated or redundant reports.
• Rezazadeh, A., Li, Z., Lou, A., Zhao, Y., Wei, W., Bao, Y. Collaborative Memory: Multi-User Memory Sharing in LLM Agents with Dynamic Access Control. arXiv:2505.18279, 2025 (preprint). Private and shared memory tiers with provenance attributes and time-varying access control.
• Margalit, Y., Cohen-Inger, N., Avram, E., Taig, R., Margalit, O. Governed Shared Memory for Multi-Agent LLM Systems. arXiv:2606.24535, 2026. The four failure modes, the four memory scopes, declared derivation chains, and the near-duplicate gate that starved contradiction detection (section 9.2).
• Cuadros, D. F., Maiga, A.-A., Meskhidze, H., Curtis-Trudel, A. Governed Collaborative Memory as Artificial Selection in LLM-Based Multi-Agent Systems. arXiv:2605.04264, 2026. Selection regimes for shared memory, when human ratification is useful, and its failure modes.
• vectr, CHANGELOG.md, "Team mode (shared central instance)" (1.1.0); the promotion tool (1.3.0); revocation without deletion (1.5.0); drift rendering on anchored notes (1.6.0); anchors hashed at write time (1.11.0); staleness re-derived from live hashes (1.12.0). Every "shipped" row in the table in Section 09.
• vectr source at commit 726e798, _hash_path_content. The anchor hash: SHA-256 over the file's bytes, truncated to 16 hex characters.
• vectr, benchmarks/injection_utility/README.md, measured result and channel parity. The declined uncorroborated note, and the run in which the agent applied one fix from a note while declining its other instruction.