Four Ways Shared Memory Breaks That One Agent Never Sees — and Why Nobody Has Measured Whether a Bigger Window Helps

Give one agent a memory and the hard question is retrieval: can the model find the right thing. Give twenty agents the same memory and retrieval stops being the hard question. The hard questions become who is allowed to read this row, which version of it is current, where it came from, and whether it should have crossed an agent boundary at all. A June 2026 paper names four ways this breaks. None of the four is a capacity problem, and — the part worth carrying away — nobody, including that paper, has run the experiment that would show whether a bigger context window helps.

Primary

arXiv:2606.24535, *Governed Shared Memory for Multi-Agent LLM Systems*, Yanki Margalit, Nurit Cohen-Inger, Erni Avram, Ran Taig, Oded Margalit. v1 only, submitted 23 Jun 2026 13:04:14 UTC, 15 pages. Affiliations on the paper: Caura.ai and Ben-Gurion University of the Negev.

System under test

MemClaw, described in the paper as "a production multi-tenant memory service", reachable at memclaw.net — which on 2026-08-26 returned HTTP 301 to caura.ai. The GitHub repository caura-ai/caura describes itself as "Caura (formerly MemClaw)". This is the authors' own commercial service, which the paper states plainly in §10 and which you must carry with every number below.

Harness

ArgusFleet, "an open-source Python 3.12 evaluation harness", cited as github.com/caura-ai/argusfleet, traces "committed under traces/ in that repository (commit 2c55bb5)". See [What does NOT work](#what-does-not-work) for what that URL returned to us.

Measurement dates that matter

all four experiments were run against a freshly-provisioned tenant on 2026-05-30; one finding was remediated server-side and re-probed on 2026-05-31. The paper was submitted 24 days later. Cite the measurement dates, not the submission date.

Context sources, marked as such and not load-bearing for anything above

arXiv:2606.30306v1 (survey, 29 Jun 2026) and arXiv:2606.28349v1 (HMARS, 3 Jun 2026).

The four failure modes, in the paper's own words

*Regime: citational. Source: arXiv:2606.24535v1 §4, locally extracted. Quoted in full because the definitions are two sentences each and a paraphrase of a two-sentence definition is just a worse definition.*

The section opens: "We identify four primary fleet-memory failure classes."

1. Unauthorized Leakage

> An agent retrieves memory outside its authorized scope.

> *Example* A customer-support agent retrieves billing notes intended only for finance agents.

> *Implications* Unauthorized leakage introduces privacy risk, tenant-isolation failures, > compliance exposure, and operational unpredictability. Naive semantic retrieval architectures > are especially vulnerable because retrieval eligibility is governed primarily by embedding > similarity rather than by explicit policy enforcement.

2. Stale Propagation

> Memory updates fail to synchronize correctly across agents.

> *Example* One agent updates a user's shipping address while another agent continues retrieving > outdated state.

> *Implications* Stale propagation produces inconsistent workflows, contradictory actions, > degraded user trust, and operational instability. The eventual-consistency window between write > and read becomes part of the system's latency budget, not an implementation detail.

3. Contradiction Persistence

> Conflicting memories coexist without resolution.

> *Example* Two mutually incompatible user preferences remain simultaneously retrievable.

> *Implications* Append-only retrieval systems often lack explicit supersession semantics, > allowing outdated or contradictory memories to persist indefinitely. Downstream agents that read > both have no principled way to choose between them.

4. Provenance Collapse

> Retrieved memories cannot be traced to their origin.

> *Example* An agent retrieves a fact without attribution to the original writer, source system, > or timestamp.

> *Implications* Without provenance, debugging becomes guesswork, auditability weakens, and > governance guarantees become unverifiable: the system cannot demonstrate *how* a particular fact > entered the store, only that it is present.

The paper formalises only the first of the four. It defines a scope-soundness invariant it calls Inv-Scope — w_i ∈ r_j ⟹ auth(a_j, s_i, G), "no agent receives a memory its identity is not entitled to under the row's scope" — and states that "Inv-Scope is the formal content of the unauthorized-leakage failure mode (§4): a leak is exactly a violation of it." The other three modes are given prose definitions and experiments, not invariants.

Long context does not solve any of the four — as an argument, not a measurement

*Regime: citational for what the paper asserts; the mapping onto the four modes is OUR inference and is marked below. Neither is a measurement — see the last paragraph of this section.*

The paper's §2.1, verbatim and in full:

> Long-context and retrieval-augmented methods improve how much relevant history a model can > access [10, 9]. But they primarily optimize recall within an isolated interaction, not > governance. Larger context windows do not by themselves provide scoped access, temporal > consistency, provenance, or synchronization; multi-agent deployments therefore require memory > systems that answer not only *can the model retrieve this*, but *should this agent see this > version*.

And in the abstract:

> These findings support the central claim that long-context retrieval alone is insufficient for > production multi-agent memory: governed shared memory requires explicit systems-level > abstractions, and live evaluation is necessary to expose the enforcement and pipeline-ordering > failures that design-only treatments miss.

And, set off as a display line in §3:

> AI memory is evolving from a context-window problem into a distributed systems problem.

*Inference, ours, NOT stated by the paper:* the four properties §2.1 says a bigger window does not provide line up one-to-one with the four failure modes — scoped access with unauthorized leakage, synchronization with stale propagation, temporal consistency with contradiction persistence, provenance with provenance collapse. The paper never draws that mapping itself. It is an obvious reading and we think it is the right one, but it is a reading.

And now the honest part, which is also the paper's own. §10, verbatim:

> *No comparand.* We do not compare against a baseline (e.g., a long-context-only configuration, > or an alternative memory implementation). The architectural claims of §5 stand on the > failure-mode taxonomy and the implementation, but the empirical claims would be sharper with a > comparison condition.

So *long context does not fix these four* is, in this paper, an argument, not a measurement. It is a good argument — an access-control violation is not a recall failure, and no amount of window makes a request carry an identity it did not have — but nobody has run the experiment where the same workload is served by a long-context-only configuration and the failure counts compared. If you cite this page for the claim, cite it as an argument. The sibling page Effective Context vs Advertised Context: Which Number Actually Bounds Your Agent covers the separate and better-measured question of whether the advertised window is even usable; this page is about a problem the window size does not touch either way.

What was actually measured, with the base under every number

*Regime: citational (values as printed in arXiv:2606.24535v1 Table 2 and §8) with an attested layer: we recomputed all eleven Wilson intervals and the denominators, eleven of eleven matched. All figures are from a single tenant of a single service on 2026-05-30.*

Four experiments, one per failure mode, "at N=200 (planned probes/writes per experiment)".

| Failure mode | Experiment | Headline result | Base | |---|---|---|---| | Unauthorized leakage | scope probes | search leak rate 0.439 [0.365, 0.516] | 72 of 164 expected-deny probes | | | | search miss rate 0.143 [0.057, 0.315] | 4 of 28 expected-allow probes | | | | tenant-key GET exposure 1.000 [0.977, 1.000] | 164 of 164 — read the caveat below | | Stale propagation | visibility + window | cross-fleet leak 0.000 [0.000, 0.046] | 0 of 80 foreign-fleet probes | | | | fleet-sibling visibility 0.975 [0.929, 0.991] | 117 of 120 intra-fleet probes | | | | write→visible p50 0.83 s, p95 1.63 s | 8 facts, 250 ms poll granularity, one at a time, deliberately uncontended | | Contradiction persistence | contradictory write pairs | detection rate 0.490 [0.422, 0.559] | 98 of 200 fact-runs | | | | detection when both writes admitted 1.000 [0.959, 1.000] | 90 of 90 fact-runs | | | | stale_read_rate 0.000 | 0 of 200 fact-runs returned two active rows | | | | write latency p50 1,840 ms, p95 4,861 ms, p99 19,319 ms | 194 writes that completed, under sustained concurrency | | Provenance collapse | derivation-chain walks | completeness and writer-identity accuracy 1.000 [0.929, 1.000] | 50 chains of depth 4 = 200 writes | | | | depth fidelity 1.00 (no CI printed) | same 50 chains | | | | per-hop fetch p50 291 ms, p95 491 ms, p99 1,076 ms | across those 50 chain walks |

Three bases deserve to be pulled out of the table because they are where a careless citation goes wrong.

The write→visible window rests on eight facts. Not 200. The paper is explicit about why — the rate-phase probes measure harness scheduling rather than server lag — and explicit about the cost: "the window is measured at 250 ms resolution on 8 facts, so it resolves 'effectively immediate' but not a sub-250 ms value". Eight observations at 250 ms granularity is enough to say "one search round-trip" and not enough to say anything about a tail.

The 1.000 exposure figure is not a leak rate. It was collected with a *tenant-scoped* key, which is tenant-wide by design. The paper says so in the Table 2 caption: those rows "should be read as exposure under tenant authority, not by themselves as a sub-tenant policy violation." See [What does NOT work](#what-does-not-work).

The headline architectural finding rests, as measured, on four probes. The real sub-tenant question was settled by a focused probe reported in Table 3 — four rows, four GET-by-id calls with different credentials — showing that an agent bound to fleet-0 at trust=1, below the documented trust=2 cross-fleet-read rung, successfully fetched a fleet-1 row. Inspecting the handler confirmed the cause: GET /memories/{id} checked only the tenant predicate and "never consulted the caller's fleet, agent, the row's visibility scope, or the trust level, so the resolved agent_id was discarded." The remediation re-probe the next day is much larger — the paper says 96 probes, though it itemises only 84 of them; see [What does NOT work](#what-does-not-work). The paper names the asymmetry itself: the open state "is no longer reproducible against the live service, so it rests on the dated probe (Table 3) and the get_memory handler reading rather than a replayable trace."

That is a four-observation base for the finding the paper is most quoted for. It may well be right — a code reading plus a demonstrated violation is real evidence — but it is a defect demonstration, not a rate.

The three findings that transfer to systems you build

*Regime: citational for the mechanism as described; the generalisation past MemClaw is ours and is marked. These are the parts of the paper that are useful whether or not you ever touch this vendor.*

A synchronous dedup gate in front of an asynchronous contradiction detector starves it. This is the best thing in the paper. MemClaw evaluates near-duplicates *pre-commit* and returns HTTP 409; it evaluates contradictions *post-commit* and asynchronously. The paper: "The pathological case is intrinsic: a contradiction phrased naturally ('X is A' then 'X is B') is near-identical text, so the very writes the detector exists to resolve are the ones most likely to be 409'd at the gate." Measured consequence: 206 of 400 planned writes rejected before reaching the detector, which is what caps the overall detection rate at 0.490 while the conditional rate is 90/90. The paper does not claim this is all mechanism — it says the rejections are "partly the genuine dedup-pre-empts-contradiction effect... partly limited prose diversity in our workload generator" and that "we do not cleanly separate the two". Their proposed fixes: run structural contradiction detection first when a write carries an RDF triple, or widen the near-duplicate threshold for such writes. *Ours, not the paper's:* this is a shape, not a MemClaw bug. Any store that dedups on embedding similarity before it reasons about assertions will reject exactly the writes it most needs to see, because an update and a near-duplicate are the same string to an embedding. If your write path has a similarity gate and a conflict resolver, check which one runs first, and check whether the caller notices a 409.

Ordering is stable across runs, so the 0.490 is not noise. Four independent N=200 runs gave both-admitted 90–91 and detections 96–100, a rate band of 0.48–0.50. That is a stability claim with its base stated — four runs — and it is the kind of thing most papers omit.

Where you pay for consistency is a design choice, and it is visible. Under write_mode = strong MemClaw enriches synchronously, so a sibling's first search after the write already returns the row (p50 ≈ 0.83 s, one search round-trip). The bill arrives in write latency instead: p50 1,840 ms, p95 4,861 ms, p99 19,319 ms. *Read those two numbers as two measurements, not as one tradeoff curve:* the 0.83 s comes from the propagation experiment's window phase, 8 facts polled one at a time and deliberately uncontended, while the write-latency percentiles come from the contradiction experiment's 194 completed writes under sustained concurrency. Different phase, different workload, different experiment. The paper is clear about this and we repeat its framing rather than smoothing it: "The window phase, deliberately uncontended, measures the visibility floor; the write-latency tail is the price the same consistency guarantee charges under load." The architectural point survives the caveat — "the budget a multi-agent orchestrator must plan against is the write, not a visibility tail" — and a 19-second p99 write is a real thing to plan around, which the paper prints rather than buries.

The three propagation misses are a retrieval failure, not a propagation failure. Worth its own line because it is where this page's subject collides with the one next door. Fleet-sibling visibility was 117/120; the paper attributes all three misses to "writes whose canary ranked below the top-*k* under embedding-similarity search (a recall effect, not a propagation failure)". So even in the experiment that came out clean, the residual error was embedding retrieval, not governance. That is the same assumption the leakage mode indicts — "retrieval eligibility is governed primarily by embedding similarity" — and it has a hard geometric limit, documented in The Geometric Ceiling of Single-Vector Retrieval: What arXiv 2508.21038 Proves, and the Four Things It Does Not.

Operational detail worth stealing

the service caps writes at 10 per second per tenant (HTTP 429). Because provenance writes are sequential within a chain, an unthrottled run loses the whole remainder of any chain whose intermediate write is rejected. Throttling the client to 8 writes/s "is what separates the complete reconstruction reported here from earlier runs that lost chains to rate-limited writes." If you are benchmarking anything chain-shaped against a rate-limited API, this failure mode will find you.

Nobody has published how often these four fail in production

*Regime: documented absence. This is a claim about what we looked for and did not find, bounded by a search we describe; it is not a claim that no such measurement exists.*

We went looking for a public measurement of the *frequency* of these four failures in a real deployment. What we found:

- arXiv:2606.24535v1 itself is, as far as we can tell, the only public measurement of any of the four against a live production service. It is a self-evaluation of the authors' own product, on one freshly-provisioned tenant, with no comparand, at N=200 planned trials per experiment. The paper says the honest version of this in §10: "An independent replication, which the open harness enables against any wire-compatible service, would carry more weight than our own numbers." - The nearest neighbours are lab evaluations, not deployment measurements. We fetched the arXiv abstract pages of Collaborative Memory (arXiv:2505.18279), G-Memory (arXiv:2506.07398), MIRIX (arXiv:2507.07957) and MEXTRA (arXiv:2502.13172) on 2026-08-26. Each proposes or attacks a system and evaluates it on constructed tasks; none of the four abstracts reports rates observed in a running multi-tenant deployment. The paper makes a similar observation, but about three of those four, not all of them — its §2.2 sentence "none treats temporal contradiction-resolution and supersession as a first-class memory operation, and none reports enforcement measured against a live service" is scoped to G-Memory, MIRIX and Collaborative Memory. MEXTRA is discussed separately in §2.4 as an attack surface, and that sentence does not cover it. Do not stretch the quote across all four; we nearly did. - A 435-work survey documents the same gap on a much bigger corpus. arXiv:2606.30306v1 codes 435 works and reports, verbatim: "Coverage thins sharply on the governance end. Authority is the rarest axis at 72 of 435. Among lifecycle stages, audit (88), forget (66), and especially rollback (27) trail far behind retrieval. Only twenty-seven of 435 works expose any rollback mechanism for state-affected decisions, and none in the corpus reports recovery success or cost after corruption." Their multi-agent-and-shared-state part (P6) is the smallest of the survey's nine parts, at 23 of 435 — read off their Table 3, where the nine parts run 27 / 117 / 33 / 52 / 53 / 23 / 25 / 25 / 80, which we re-added to 435. Carry two caveats with it, both theirs: "These counts are scoping estimates, not a census", and the reliability check is weaker than its headline. Pooled second-coder agreement on a blind 236-work sample was 0.82 on lifecycle stages and 0.74 on state axes — but Cohen's κ was only 0.58 and 0.44, which the survey itself calls "moderate agreement, as expected for fine-grained multi-label coding". Quote the κ alongside the agreement or you are quoting the flattering half. - Where the field's energy is going instead is retrieval quality. HMARS (arXiv:2606.28349v1, 3 Jun 2026) is a hierarchical *multi-agent* memory system, and its abstract — the only part we read — is about evidence coverage and answer quality against "retrieval, reranking, full-context, graph-based, and agentic long-context baselines". The words *scope*, *authority*, *stale*, *provenance*, *governance*, *access control* and *permission* do not occur in it; we checked by string search. We make no claim about the paper's results; the claim is only about what its abstract is about, which is the point: even work explicitly labelled multi-agent memory is mostly still optimising recall.

Bound on this section

this session had no web-search budget, so the search above is citation-following plus direct arXiv fetches, not a systematic sweep. A single production postmortem or vendor incident report we did not see would falsify the first bullet. If you have one, it supersedes this section.

What does NOT work

Citing "1.000 leak rate" from Table 2. It is the most quotable number in the paper and it does not mean what it looks like. It was measured with a tenant-scoped credential, which is tenant-wide by design; the paper's own caption warns against reading it as a policy violation. The finding that *is* a violation is the four-row Table 3 probe, and it was fixed the next day.

Citing 0.490 as "the contradiction detector works half the time". The 0.490 is an *admission* effect. Conditional on both contradictory writes being admitted, supersession was established in 90 of 90 cases. The number to quote depends on the question: 0.490 answers "if I fire two contradictory writes at this API, how often does the store end up resolved", 90/90 answers "does the detector work".

Taking the 96-probe remediation figure without adding it up. *Regime: attested, ours, 2026-08-26.* The paper's answer to its own worst finding is a re-probe on 2026-05-31 described as "96 GET-by-id probes across four fleets and both trust levels" with "total leaks 0/96". It then itemises those probes as trust-1 cross-fleet denied 0/36, trust-2 cross-fleet admitted 36/36, and same-fleet controls 12/12. That is 84. Twelve probes are stated but never itemised, in either §9.1 or the Table 3 caption, and the paper offers no fourth cell. The gap does not overturn the remediation — 0/36 on the exact condition that failed is the load-bearing cell and it is intact — but if you are quoting "96 probes" as the strength of the fix, quote 84, or quote the 0/36 directly. We found this by doing the arithmetic the paper invites; the traces that would close it are in the repository that 404s.

Reading `supersedes_id` from the synchronous write response. The paper reports having done this itself in an earlier version and getting "a spurious 0/200". Detection is post-commit and asynchronous; only a GET-by-id re-fetch after a settle window surfaces the true outcome. If you benchmark a memory service's conflict resolution and get a clean zero, suspect your read path before you write up the null.

Using a multi-valued predicate for a contradiction test. Verbatim: "the structural detector only runs for predicates the server treats as single-valued; our earlier deployment_region was not one, so the RDF path was silently skipped." Silently. The test reported a working detector as absent, and nothing in the response said so.

Measuring time-to-visibility by seeding all writes and then draining probes. It measures your own client. The reported p50 "grows with probe count", and an earlier version of this same work reported tens of seconds for exactly this reason before the authors caught it. Poll each write immediately and continuously from write completion, one at a time.

Assuming tenant isolation implies sub-tenant isolation. The measured system enforced tenant boundaries uniformly on every path and enforced fleet/agent scope on only one of two read paths, and only partially there. The paper calls this "bimodal" enforcement. Two read paths to the same row is two policy surfaces, and only one of them had been checked.

Assuming an authenticated identity is an enforced identity. The gateway correctly resolved the caller's agent identity and injected it as X-Agent-ID; the read handler then "discarded" it. The authors initially conjectured the gap was an artifact of the authentication model and their own probe refuted their conjecture. Resolving identity and enforcing it are different lines of code.

Reproducing the study today, at the URL the paper gives. *Regime: attested, ours.* On 2026-08-26 at 08:15:31Z, and again at 08:31:43Z with identical results, https://github.com/caura-ai/argusfleet returned HTTP 404; so did the GitHub API for that repository, the raw README, and pypi.org/pypi/argusfleet/json. The org caura-ai exists and had 8 public repositories at that moment, none named argusfleet; a GitHub repository search for the name returned total_count: 0. The org is not abandoned — caura-ai/caura reported pushed_at 2026-08-26T08:27:18Z, four minutes before our second probe — so this is an absent repository in a live org, not a dead account. The commit 2c55bb5 under which "the event traces backing every number in this paper" are said to be committed is therefore not publicly reachable from where we stand. This does not mean the traces do not exist: the repo may be private, renamed, or withdrawn. It does mean that the paper's central defence against its own self-evaluation bias ("we counter it by committing the re-probe trace, not just asserting the remediation") could not be exercised by us on 2026-08-26. Anyone can re-run the check in ten seconds and contradict us.

Taking §2.2's characterisation of the other memory systems at face value. The paper writes of MemGPT/Letta, Mem0, Zep, LangMem, A-MEM and AutoGen's memory subsystems: "Most assume single-agent retrieval against an append-only store with largely unconstrained access, weak provenance semantics, and limited temporal resolution." That is a vendor characterising its competitors, and we did not verify it. Two tensions are visible without leaving the paper's own bibliography and one page of fetching:

- The work cited for Zep is arXiv:2501.13956, *Zep: A Temporal Knowledge Graph Architecture for Agent Memory*, whose abstract (fetched 2026-08-26) describes "a temporally-aware knowledge graph engine... while maintaining historical relationships". "Limited temporal resolution" is a strange thing to say about a system whose title and thesis are temporality. - Collaborative Memory (arXiv:2505.18279) does the governance work this paper treats as missing, and the paper concedes it: §2.2 credits it with adding "dynamic access control and immutable provenance over a shared multi-user store". Its own abstract, fetched the same day, confirms independently: "asymmetric, time-evolving access controls encoded as bipartite graphs" and "Each fragment carries immutable provenance". If you want scoped multi-user memory with provenance and no vendor evaluating itself, read that one first. What it does not do — and this is the primary's real contribution, not a marketing line — is treat temporal supersession as a first-class operation or measure enforcement against a running service.

For what is actually verified about these systems' published numbers, see Three LoCoMo Scores Side by Side Are Not a Ranking: the denominator, the judge, and the one knob worth nine points; treat §2.2 as positioning until someone measures it.

How to use this if you are building

The taxonomy is worth more than the numbers, and it costs nothing to adopt. For a shared store, write down four answers before you write code:

1. Scope — for every read path, not just the one you tested. Enumerate the paths. The measured system had two and enforced on one. 2. Time — what supersedes what, and does the older row become unreadable or merely lower-ranked. "Append-only" is an answer, and it is the answer that makes contradiction persistence permanent. 3. Provenance — can a retrieved row name its writer after a storage round-trip. This was the one clean positive in the paper (50/50 chains at depth 4), which suggests it is the cheapest of the four to get right, and it is the one that makes the other three debuggable. 4. Propagation — what makes a fact cross an agent boundary, and is that the same privilege as an administrative re-home. The measured system conflated them behind one trust_level ≥ 3 gate on POST /memories/redistribute, and the paper argues that is wrong: fleet-internal propagation between siblings is "a normal operation in any non-trivial multi-agent workflow", not a migration.

Related: The Binding Constraint Is Verified Context, Not the Model or the Rail (our prediction) for the thesis that verified context, not model capability, is the binding constraint on long-horizon agent work — this page is one of the mechanisms by which that would be true, and it is an argument on both ends, not a measurement.

Our interest, stated

Sinapsi sells shared memory for AI agents. Caura.ai, whose paper this page is built on, sells into the same market, so the two adverse findings above that are ours — the 404 probe and the twelve unitemised probes — are one competitor's findings about another, and should be weighed as such; both are stated as a procedure with a timestamp rather than as a conclusion precisely because anyone can re-run them in minutes and contradict us. Being in the category this page describes is also the reason the page contains no measurement of our own system and no claim that we handle any of the four failure modes. We have not run this harness against ourselves, and until we do and publish the traces, we are in exactly the position the paper's §10 describes and have less standing than it does, because it at least measured something. Everything above is checkable without buying anything: three arXiv ids, a PDF you can extract yourself, eleven Wilson intervals you can recompute, one sum that does not close, and four curl commands.

Supersession

Four things would change this page and should be sent to it.

- A public measurement of any of the four failure modes against a live service by someone other than its vendor. That is the missing artifact in this whole area, and the paper says so itself. - The ArgusFleet repository becoming reachable, or a statement about where the traces went. The "What does NOT work" entry above is dated 2026-08-26 08:31:43Z and should be re-run before being cited, not copied. - An accounting of the twelve unitemised probes in the 2026-05-31 re-probe — from the authors, or from the traces if they resurface. That would close the one arithmetic gap we found. - A long-context-only comparand. Until someone runs the same workload through a configuration that has only a big window, *a bigger context does not fix these four* remains an argument we find convincing and cannot show you a number for.