Governed Shared Memory for Multi-Agent LLM Systems

# Governed Shared Memory for Multi-Agent LLM Systems
Source: [https://arxiv.org/html/2606.24535](https://arxiv.org/html/2606.24535)
Yanki Margalit1, Nurit Cohen\-Inger2, Erni Avram1, Ran Taig1, and Oded Margalit2, 1Caura\.ai 2Computer Science and Information, Ben\-Gurion University of the Negev

###### Abstract

AI memory systems are increasingly moving beyond isolated chatbot histories toward shared state used by fleets of cooperating agents\. In this setting, memory is not only a retrieval problem: it becomes a governed distributed\-systems problem involving scoped access, temporal correctness, provenance, synchronization, and policy\-controlled propagation\. We introduce a systems architecture for governed shared memory in multi\-agent LLM environments\. The architecture formalizes the fleet\-memory problem, identifies four failure modes—unauthorized leakage, stale propagation, contradiction persistence, and provenance collapse—and defines primitives for scoped retrieval, temporal supersession, provenance tracking, and policy\-governed memory propagation\.

We instantiate these primitives in MemClaw, a production multi\-tenant memory service, and evaluate them using ArgusFleet, a reproducible harness that exercises the live REST API along four governance dimensions\. Our evaluation is a measurement of one production service rather than a comparison against baselines, and its negative results are central to the contribution\. Provenance is the cleanest positive result: all 50 depth\-four derivation chains reconstruct with correct writer identity at sub\-second per\-hop latency\. Propagation is correct where measured, with high intra\-fleet visibility and no observed cross\-fleet leakage; tight per\-fact polling shows that under strong write mode, write\-to\-visible latency is effectively one search round\-trip rather than the tens\-of\-seconds delay suggested by a naive batched probe schedule\.

The live evaluation also surfaces two production\-relevant architectural issues\. First, scope enforcement was initially asymmetric across API paths: tenant isolation held, but sub\-tenant scope was not enforced on direct GET\-by\-id for agent\-scoped credentials; the gap was disclosed and remediated during the study\. Second, contradiction supersession works when conflicting writes are admitted, but a synchronous near\-duplicate gate can reject contradictory writes before the asynchronous contradiction detector observes them\. 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\.

## 1Introduction

![Refer to caption](https://arxiv.org/html/2606.24535v1/figure_1_system_overview.png)Figure 1:System overview\. A fleet of cooperating agents writes to and reads from governed shared memory through MemClaw’s REST API\. MemClaw exposes four governance dimensions—scope, time, provenance, and propagation—corresponding to who may read a memory, which version is current, where a memory came from, and how it moves across agent boundaries\. ArgusFleet probes the same API surface with one experiment per dimension: leakage probes scope enforcement, contradiction probes temporal supersession, provenance walks derivation chains, and propagation measures authorized visibility and cross\-fleet leakage\. Stale propagation is evaluated jointly through contradiction supersession, where outdated rows are marked non\-active, and propagation latency, where newly written facts are polled until visible to authorized readers\.Large\-language\-model systems are rapidly evolving from isolated assistants into fleets of interacting agents\. Enterprise copilots, workflow orchestrators, customer\-support systems, research agents, and automation pipelines increasingly rely on persistent memory to coordinate behavior across tasks and time\. Most existing memory systems, however, were designed around a single\-agent abstraction — one user, one conversation, one retrieval stream, one context window — and this assumption breaks under fleet\-scale deployments\.

When multiple agents interact through shared memory, new correctness and governance requirements emerge that are absent from the single\-agent setting\. The system must answer who is allowed to retrieve which memory, how conflicting facts are resolved when two agents disagree, how knowledge propagates safely across agent boundaries, whether each retrieved memory can be traced back to its writer, and how stale memories are invalidated when the underlying state changes\. These are not retrieval\-quality questions\. They are distributed\-systems and database\-consistency questions in retrieval clothing\.

Current AI memory systems largely optimize for properties inherited from the single\-agent world: retrieval relevance, conversational recall, long\-context compression, and semantic similarity\. Production multi\-agent deployments require an additional layer on top: scoped visibility, policy enforcement, temporal correctness, synchronization semantics, and provenance guarantees\. We argue that AI memory is therefore evolving from a context\-window problem into a governed distributed\-memory problem, and that this transition warrants the same systems\-level attention historically devoted to databases, event\-sourcing, and synchronization infrastructure\.

This paper introduces a systems architecture for governed shared memory under that framing and presents MemClaw as a reference implementation deployed at fleet scale\. We also introduce ArgusFleet, an evaluation harness that lets the resulting primitives be measured empirically against a live production service\.

### 1\.1Contributions

This paper makes three contributions\.

First, we formalize the fleet\-memory problem for multi\-agent LLM systems, modeling shared memory as governed operational state with scope, provenance, and temporal supersession\. We identify four resulting failure modes: unauthorized leakage, stale propagation, contradiction persistence, and provenance collapse\.

Second, we propose an architecture for governed shared memory, centered on scoped retrieval, temporal contradiction resolution, provenance tracking, and policy\-governed propagation\. We instantiate the architecture in MemClaw, a production multi\-tenant memory service, and introduce ArgusFleet, a reproducible harness that probes these primitives through the live REST API\.

Third, we report a live\-service measurement of MemClaw using ArgusFleet\. The results show complete provenance reconstruction and correct propagation where measured, but also expose two production\-relevant issues: a remediated𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id sub\-tenant scope gap and a pipeline\-ordering interaction in which synchronous deduplication can pre\-empt asynchronous contradiction detection\.

## 2Background and Related Work

### 2\.1Long\-Context Retrieval

Long\-context and retrieval\-augmented methods improve how much relevant history a model can access\[[10](https://arxiv.org/html/2606.24535#bib.bib15),[9](https://arxiv.org/html/2606.24535#bib.bib14)\]\. 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*\.

### 2\.2Agent Memory Systems

A line of recent agent\-memory architectures — including MemGPT and its successor Letta\[[13](https://arxiv.org/html/2606.24535#bib.bib1)\], Mem0\[[1](https://arxiv.org/html/2606.24535#bib.bib2)\], Zep\[[14](https://arxiv.org/html/2606.24535#bib.bib3)\], LangMem\[[8](https://arxiv.org/html/2606.24535#bib.bib4)\], A\-MEM\[[22](https://arxiv.org/html/2606.24535#bib.bib9)\], and the memory subsystems of AutoGen\[[21](https://arxiv.org/html/2606.24535#bib.bib5)\]— treats memory as a stand\-alone component layered on top of an LLM\. Most assume single\-agent retrieval against an append\-only store with largely unconstrained access, weak provenance semantics, and limited temporal resolution\. These assumptions are reasonable for chatbot\-style interactions in which one user converses with one assistant; they become problematic under multi\-agent shared\-memory workloads where different agents have different visibility, different write authority, and different reasoning windows\.

A second, very recent line moves explicitly to*shared*multi\-agent memory and is the closest neighbour to our setting\. G\-Memory\[[23](https://arxiv.org/html/2606.24535#bib.bib6)\]formalizes multi\-agent memory as a three\-tier interaction/query/insight graph and argues, as we do, that single\-agent memory does not transfer to multi\-agent systems; MIRIX\[[20](https://arxiv.org/html/2606.24535#bib.bib8)\]organises a multi\-agent memory across typed stores; and Collaborative Memory\[[15](https://arxiv.org/html/2606.24535#bib.bib7)\]adds*dynamic access control*and immutable provenance over a shared multi\-user store\. These systems establish that shared memory, governance, and provenance are an active concern — but none treats temporal contradiction\-resolution and supersession as a first\-class memory operation, and none reports enforcement measured against a live service\. Our contribution is the unification of all five components \(A,M,G,P,TA,M,G,P,T\) under one formalism, with temporal supersession \(TT\) as the element prior shared\-memory work leaves implicit, and an empirical harness that exercises each against a running system\.

### 2\.3Distributed Systems and Shared State

Once memory is genuinely shared across agents, the operational concerns mirror those of traditional distributed systems: synchronization, consistency, access governance, temporal ordering, event propagation, and auditability\. Production AI memory systems therefore increasingly resemble distributed databases\[[5](https://arxiv.org/html/2606.24535#bib.bib19),[2](https://arxiv.org/html/2606.24535#bib.bib20)\], event\-sourcing and weakly\-connected replicated stores\[[18](https://arxiv.org/html/2606.24535#bib.bib17),[17](https://arxiv.org/html/2606.24535#bib.bib18)\], synchronization layers\[[7](https://arxiv.org/html/2606.24535#bib.bib16)\], and governance middleware\[[16](https://arxiv.org/html/2606.24535#bib.bib21),[6](https://arxiv.org/html/2606.24535#bib.bib22)\]— not the retrieval indexes from which the agent\-memory line of work descended\. This suggests that memory infrastructure may become a foundational systems layer for future AI architectures, and that the methods and primitives developed for distributed state are the right vocabulary for reasoning about it\.

### 2\.4Memory Governance, Security, and Privacy

A parallel and equally recent line treats agent memory as a security and privacy surface rather than a retrieval index\. MEXTRA\[[19](https://arxiv.org/html/2606.24535#bib.bib10)\]shows that an agent’s memory module is a concretely extractable attack surface: crafted queries alone recover private user–agent interactions in a black\-box setting, motivating exactly the scoped\-retrieval guarantee we formalize\. On the enforcement side, CaMeL\[[4](https://arxiv.org/html/2606.24535#bib.bib11)\]attaches capability and provenance metadata to values and enforces policy at tool\-call time, while Fides\[[3](https://arxiv.org/html/2606.24535#bib.bib12)\]gives a formal information\-flow\-control model with confidentiality and integrity labels and a planner that deterministically enforces them\. For the propagation question — whether a memory*should*cross an agent boundary — the canonical framing is contextual integrity: ConfAIde\[[12](https://arxiv.org/html/2606.24535#bib.bib13)\]shows that capable LLMs leak information in contexts humans would withhold, reframing access as a question of appropriate flow rather than static permission\. Our unauthorized\-leakage finding \(§[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\) is an instance of the classic confused\-deputy problem this literature studies: a read handler that resolves but then ignores caller identity\. We adopt these as the governance and provenance vocabulary forGGandPP, complementing the distributed\-systems vocabulary above forMMandTT\.

Finally, our evaluation framing is also related to recent work that treats LLM evaluation itself as a multi\-agent process\. PeerRank evaluates models through web\-grounded, bias\-controlled peer review among LLMs\[[11](https://arxiv.org/html/2606.24535#bib.bib25)\]\. Our use of ArgusFleet is complementary: rather than evaluating model outputs, it evaluates the governed memory substrate that multi\-agent systems rely on for persistent shared state\.

## 3The Fleet\-Memory Problem

Modern AI deployments are increasingly composed not of a single assistant but of fleets of specialised agents operating over shared persistent state\. A customer\-support agent may update a user’s billing record in a way that subsequently affects a planning agent’s schedule, an analytics agent’s dashboard, a workflow orchestrator’s routing logic, and a downstream compliance system’s audit trail\. A research agent may surface a finding that synthesis agents, verification agents, reporting systems, and autonomous workflows all need to consume hours or days later\. In these environments, memory is no longer “conversation history”; it is shared operational state, and the correctness story it must support has more in common with shared\-storage subsystems than with retrieval indexes\.

This shift changes the nature of the problem\. Traditional LLM memory architectures optimize for semantic recall, conversational continuity, long\-context retrieval, and summarisation quality\. These optimizations are sufficient when one agent interacts with one user over one conversational stream\. They break down when many agents write to shared memory, when visibility differs across roles, when facts evolve over time, and when correctness matters operationally rather than only narratively\. Under fleet\-scale workloads, the memory subsystem has to answer which agents are allowed to retrieve which memories, what happens when two agents write contradictory facts, how stale memories are superseded, whether every retrieved memory can be traced to its source, and how knowledge propagates safely across agent boundaries\. These are distributed\-systems questions, not retrieval questions\.

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

The transition introduces a new set of requirements — governance, temporal correctness, synchronization, provenance, scoped visibility, and policy\-aware retrieval — that the single\-agent memory line of work does not address\. We refer to systems that meet these requirements asfleet\-memory systems\.

### 3\.1Fleet\-Memory Systems

We define a fleet\-memory system as:

F=\(A,M,G,P,T\)F=\(A,M,G,P,T\)
where:

- •AArepresents a set of interacting agents,
- •MMis a shared memory substrate,
- •GGis a governance and policy layer,
- •PPrepresents provenance metadata,
- •TTdefines temporal ordering and supersession semantics\.

Unlike single\-agent conversational memory, fleet\-memory systems must maintain correctness across interacting reads and writes performed by multiple autonomous actors over time\.

This introduces challenges analogous to:

- •distributed consistency,
- •access control,
- •synchronization,
- •event sourcing,
- •and state resolution\.

The central challenge is no longer merely retrieving semantically relevant information; it is maintaining operationally correct shared state\.

### 3\.2Memory Operations

A memory write operation is defined as:

wi=\(ai,ci,si,ti,pi\)w\_\{i\}=\(a\_\{i\},c\_\{i\},s\_\{i\},t\_\{i\},p\_\{i\}\)
where:

- •aia\_\{i\}is the writing agent,
- •cic\_\{i\}is the memory content,
- •sis\_\{i\}defines the visibility scope,
- •tit\_\{i\}is the temporal ordering,
- •pip\_\{i\}contains provenance metadata\.

Importantly, writes are not immutable conversational artifacts but state transitions: a later write may supersede, invalidate, restrict, or contradict prior memory\. Retrieval operations must therefore incorporate governance and temporal semantics in addition to semantic relevance\.

We define retrieval as:

rj=f​\(qj,aj,gj,tj\)r\_\{j\}=f\(q\_\{j\},a\_\{j\},g\_\{j\},t\_\{j\}\)
where:

- •qjq\_\{j\}is the retrieval query,
- •aja\_\{j\}is the requesting agent,
- •gjg\_\{j\}represents governance constraints,
- •tjt\_\{j\}defines temporal correctness conditions\.

In conventional vector retrieval systems, semantic similarity alone determines retrieval eligibility; in fleet\-memory systems, retrieval correctness additionally depends on:

- •authorization,
- •state freshness,
- •contradiction resolution,
- •provenance validity,
- •and synchronization guarantees\.

We make the authorization requirement precise, since it is the one the evaluation falsifies\. Letauth​\(aj,si,G\)\\mathrm\{auth\}\(a\_\{j\},s\_\{i\},G\)denote the predicate “agentaja\_\{j\}is entitled, under governanceGG, to view a memory carrying scopesis\_\{i\},” wheresis\_\{i\}decomposes into nested levels \(agent⊑\\sqsubseteqfleet⊑\\sqsubseteqtenant; §[6](https://arxiv.org/html/2606.24535#S6)\)\. A retrieval is*scope\-sound*when

wi∈rj⟹auth​\(aj,si,G\)\.w\_\{i\}\\in r\_\{j\}\\;\\Longrightarrow\\;\\mathrm\{auth\}\(a\_\{j\},s\_\{i\},G\)\.That is, no agent receives a memory its identity is not entitled to under the row’s scope\.Inv\-Scopeis the formal content of the unauthorized\-leakage failure mode \(§[4](https://arxiv.org/html/2606.24535#S4)\): a leak is exactly a violation of it\. A correct governed\-memory implementation must evaluate the*full*scope predicate on every retrieval path; as §[8](https://arxiv.org/html/2606.24535#S8)shows, the𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id path evaluated only the tenant projection ofsis\_\{i\}at measurement time and so violatedInv\-Scopefor any fleet\- or agent\-scoped row\. The formalism predicted a concrete violation, the experiment measured it, and the operator’s fix \(§[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\) restoredInv\-Scopeon that path — a predict→\\tomeasure→\\toremediate loop\.

This distinction becomes critical once memory evolves from passive context into shared operational infrastructure\.

## 4Fleet\-Memory Failure Modes

We identify four primary fleet\-memory failure classes\.

### 4\.1Unauthorized 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\.

### 4\.2Stale 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\.

### 4\.3Contradiction 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\.4Provenance 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\.

## 5Governed Shared Memory Architecture

### 5\.1Design Principles

The proposed architecture is built around five principles:

1. 1\.Scoped retrieval
2. 2\.Explicit provenance
3. 3\.Temporal correctness
4. 4\.Policy\-governed propagation
5. 5\.Persistent shared state

### 5\.2Memory Scopes

We define four memory scopes:

Table 1:Memory scopesSemantic similarity alone is insufficient for retrieval eligibility; every retrieval operation must additionally satisfy the governance policies attached to the scope of the candidate row\.

### 5\.3Temporal Resolution

The architecture treats memory as evolving state rather than immutable append\-only retrieval\. Each memory object carries a creation timestamp, optional supersession references, contradiction markers, provenance metadata, and a confidence state, and contradictory writes are resolved through temporal ordering and policy\-aware resolution rules rather than by silently coexisting in the store\.

### 5\.4Provenance Graph

Every memory object stores its writer identity, source system, derivation history, and modification lineage\. This metadata is what enables auditability, debugging, traceability, and compliance verification — four properties that are increasingly required of memory systems deployed in regulated environments and that distinguish governed memory from retrieval indexes\.

### 5\.5Policy\-Governed Retrieval

Retrieval consists of:

1. 1\.semantic candidate generation,
2. 2\.policy filtering,
3. 3\.temporal resolution,
4. 4\.provenance enrichment,
5. 5\.ranked delivery\.

This differs from traditional vector retrieval systems in which semantic similarity alone determines retrieval eligibility\.

## 6Reference Implementation

We instantiate the architecture of §5 in two artifacts: MemClaw, a multi\-tenant memory service, and ArgusFleet, an open evaluation harness that exercises the architectural primitives against MemClaw or any wire\-compatible implementation\.

### 6\.1MemClaw

MemClaw is a multi\-tenant governed\-memory service111[https://memclaw\.net](https://memclaw.net/)\. Each memory object carries the fields required by the architecture: tenant and fleet identifiers, writing agent, content, optional RDF triple \(⟨\\langlesubject\_entity, predicate, object\_value⟩\\rangle\), visibility scope, status, and supersession links\. The wire format additionally exposes ingestion\-side metadata \(write mode, enrichment\-pending flags\) so a caller can reason about consistency at write time\. Authentication uses anmc\_\-prefixed API key; the credential’s*kind*\(tenant\-scoped vs\. agent\-scoped\) is bound on the credential record, not encoded in the prefix\. For an agent\-scoped credential the gateway resolves the caller’s agent identity and injects it \(asX\-Agent\-ID\) before request handlers execute — a client\-suppliedX\-Agent\-IDis stripped — while tenant boundaries are enforced on every path\.

The following operations are exercised in this paper:

- •POST /api/v1/memories— write a memory with optional RDF triple and write mode \(fast,strong,auto, orstm\)\.
- •POST /api/v1/search— semantic search filtered by tenant and optional fleet/agent/status constraints; top\-kkis clamped to2020on the REST surface\.
- •POST /api/v1/entities/upsert— materialize a subject entity for RDF\-triple writes\.
- •GET /api/v1/memories/\{id\}— retrieve a memory by identifier; requires the tenant identifier as a query parameter\.
- •POST /api/v1/memories/redistribute— re\-home a memory onto a different agent; requires the caller to holdtrust\_level≥3\\text\{trust\\\_level\}\\geq 3\.

### 6\.2ArgusFleet

ArgusFleet is an open\-source Python 3\.12 evaluation harness222[https://github\.com/caura\-ai/argusfleet](https://github.com/caura-ai/argusfleet)for governed shared memory, comprising four experiments, an async REST client, a typed domain model, structured event logging, and a reproducible reporting pipeline\. It is distributed as theargusfleetpackage; we use the name ArgusFleet for the system throughout this paper\. The harness produces JSONL event traces, CSV summaries, and Matplotlib figures from each run, all derived from the same canonical event stream so analysis can be re\-executed without re\-hitting the server\. The event traces backing every number in this paper — including all fourN=200N\{=\}200contradiction runs and theN=100N\{=\}100comparison \(§[8](https://arxiv.org/html/2606.24535#S8)\) — are committed undertraces/in that repository \(commit2c55bb5\); each experiment’s reported figures andsummary\.csvregenerate deterministically from its per\-writeevents\.jsonl\.

#### Determinism\.

Every workload is seeded\. Plan structure \(fleets, agents, fact subjects, chain shapes\) is reproducible across runs sharing the same seed\. Per\-run content is salted with a run\-unique nonce so that re\-running against a stateful production service still produces semantically fresh writes rather than collisions on accumulated state\. Each run materializes a uniquely\-named output directory of the form<UTC\-timestamp\>\-<experiment\>\-seed<N\>/\.

#### Async execution\.

The client is built onhttpxandtenacitywith exponential backoff for transient transport errors, 5xx responses, and429429rate\-limit responses; other 4xx responses are surfaced to the experiment unmodified, since they are precisely the governance signal we are measuring\. Concurrency caps are configured per experiment to remain below the per\-tenant search rate limit \(100100req/min on/search\)\.

#### Domain model\.

Per\-probe and per\-write events are appended to the JSONL trace as plain dictionaries; the harness ships typed Pydantic models for the two records where typing actually pays off —MemoryScope\(the ground\-truth scope enum the leakage experiment reasons about\) andPolicyDecision\(the audit\-grade record of an observed governance outcome\)\. Translating between the dict events and the MemClaw wire schema is delegated to the async client \(§6\.1\) so the harness can be retargeted to alternative governed\-memory implementations without changing the experiment code\.

## 7Evaluation Methodology

We evaluate the four failure modes from §4 with one experiment each\. Every experiment shares the same lifecycle: a deterministic plan is materialized from the seed, writes are issued against the live service, a settle delay accommodates asynchronous server\-side enrichment, and a verification phase compares observed behaviour against an expected ground truth derived from the plan\.

### 7\.1Leakage Experiment

We instantiateF=4F=4fleets, each containingK=6K=6agents, in a single tenant\. The first agent in each fleet \(the*owner*\) writes two secrets: one with fleet scope, one with agent scope, each containing a unique canary token in metadata and substantively distinct prose in content\. Every agent then probes every secret by issuing a search whose query is the secret’s prose; the harness classifies each probe against ground truth \(does this agent’s tenant/fleet/agent identity entitle it to see this secret?\) and labels the result\.

For each probe, we record two orthogonal failure signals:

- •leak— the server returned a row the probe was not entitled to see; this is the security failure that motivates governance\.
- •miss— the server failed to return a row the probe was entitled to see; this is an availability failure that reflects retrieval recall\.

We reportleak\_rate=nleaks/nexpected\-deny\\textsc\{leak\\\_rate\}=n\_\{\\text\{leaks\}\}/n\_\{\\text\{expected\-deny\}\}andmiss\_rate=nmisses/nexpected\-allow\\textsc\{miss\\\_rate\}=n\_\{\\text\{misses\}\}/n\_\{\\text\{expected\-allow\}\}\. At the configured workload size we generate192192probes spanning164164expected\-deny and2828expected\-allow\.

To separate an authentication\-model effect from a genuine enforcement gap on the access path, we additionally run a focused*agent\-scoped*probe\. Using the tenant key we self\-provision two agent credentials \(POST /api/v1/admin/agent\-keys/provision,𝚔𝚒𝚗𝚍=𝚊𝚐𝚎𝚗𝚝​\_​𝚔𝚎𝚢\\mathtt\{kind\{=\}agent\\\_key\}\) bound to the same fleet but different trust levels — one attrust=1\\text\{trust\}=1\(write home fleet; below the cross\-fleet\-read rung\) and one attrust=2\\text\{trust\}=2\(cross\-fleet read\)\. We confirm the gateway resolves each agent’s identity viaGET /api/v1/whoami, then𝙶𝙴𝚃\\mathtt\{GET\}a row written under a*different*fleet with each credential\. Under the documented trust ladder \(0read\-only,11write\-home\-fleet,22cross\-fleet\-read,33cross\-fleet\-write\), the trust\-11cross\-fleet read must be denied if sub\-tenant scope is enforced on𝙶𝙴𝚃\\mathtt\{GET\}\.

### 7\.2Contradiction Experiment

We construct100100facts drawn from2020distinct subject–predicate templates \(e\.g\.,⟨billing\-service\-N,deployment\_region⟩\\langle\\text\{billing\-service\-N\},\\text\{deployment\\\_region\}\\rangle\)\. For each fact we run two scenarios: a*sequential*writer pair separated by a small delay, and a*concurrent*pair dispatched simultaneously\. Within each pair, both writes share the samesubject\_entity\_idandpredicatebut assert differentobject\_value\. The RDF triple is what we expect to route the second write into the server’s structural contradiction detector rather than into the embedding\-similarity dedup gate\.

We report:

- •detection\_rate— the fraction of fact\-runs in which, after a settle window, a𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id*re\-fetch*of the two rows shows a supersession edge \(supersedes\_id\) or the older row flipped to a non\-active status\. The re\-fetch is essential: contradiction detection runs*post\-commit and asynchronously*, sosupersedes\_idis never present in the synchronous write response \(reading it there — as an earlier version did — yields a spurious0\)\. The predicate must also be one the server treats as single\-valued, or its structural detector is skipped\.
- •stale\_read\_rate— the fraction of fact\-runs in which a freshstatus\_filter="active"search returned more than one row carrying the fact identifier\.
- •write\_latencypercentiles, split by whether the write triggered a contradiction\.

### 7\.3Provenance Experiment

We construct5050derivation chains of depth44\(200200total writes\)\. Each chain corresponds to a synthetic incident narrative drawn from a pool of2525operational topics \(cycled, with a per\-chain nonce keeping content distinct\) \(e\.g\.,*checkout error rate spike*,*Kafka consumer rebalance loop*\)\. The four steps in each chain correspond to*observation*,*hypothesis*,*mitigation*, and*verification*\. Each step writes a memory withmetadata\.derived\_fromencoding the parent identifier\. After all writes settle, the harness fetches the leaf and walks the chain back to the root, grading three signals:

- •completeness— every ancestor on the planned chain is reachable viaGET\.
- •accuracy— at each step the observed writer matches the planned writer\.
- •depth\_fidelity— the reconstructed chain length equals the planned depth\.

### 7\.4Propagation Experiment

The experiment has two deliberately separate phases, because the visibility*rate*and the consistency*latency*want opposite measurement regimes\.

#### Rate phase\.

A designated writer agent writes4040fleet\-scoped facts, each phrased as a substantively distinct operational statement \(drawn from4040templates\)\.33sibling readers in the same fleet and22non\-fleet readers in the same tenant then poll/searchfor the prose \(200200probes total\)\. Fleet\-sibling probes time out after3030seconds; non\-fleet probes execute a single attempt and any hit is counted as a cross\-fleet leak\. This phase scales with the fact count to tighten the rate CIs; its per\-probe latency is*not*used \(see below\)\.

#### Window phase\.

Because the rate phase seeds every fact before draining any probe through a concurrency gate, a probe’s first/searchlands long after the row is already searchable — so its time\-to\-visibility measures harness scheduling, not server lag, and inflates with probe count\. We therefore measure the write\-to\-visible window separately, on88dedicated facts \(distinct prose, so they do not dedup\-collide with the rate\-phase set\), each polled*immediately and continuously*from write completion at250250ms granularity, one fact at a time so the poll stream stays under the per\-tenant/searchbudget\. This isolates the server’s single\-write consistency window from harness scheduling\.

For each \(writer, fact, reader\) tuple we record:

- •visibility— whether the reader’s search ever returned an item carrying the fact’s canary in metadata \(rate phase\)\.
- •time\-to\-visibility— elapsed wall\-clock between write completion and the first successful read, from the window phase\.
- •is\_leak— a foreign\-fleet reader observed the canary\.

A deterministic subset of facts is additionally passed throughPOST /api/v1/memories/redistributeonto a target agent, and the harness re\-fetches each row viaGETto confirm thatagent\_idflipped to the target\.

## 8Experimental Results

We ran the four experiments against the productionmemclaw\.netservice from a single tenant\. Results are summarised in Table[2](https://arxiv.org/html/2606.24535#S8.T2)\.

#### Temporal provenance\.

All four experiments report a freshly\-provisioned tenant measured on 2026\-05\-30\. One finding — sub\-tenant scope on the𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id path \(§[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\) — was disclosed and remediated server\-side on 2026\-05\-31; we report both the as\-measured state and the verified fix, and flag the affected numbers as “as measured” where they appear\. Every other number reflects the 2026\-05\-30 state, and all are backed by committed traces \(§[6](https://arxiv.org/html/2606.24535#S6)\)\. Tenses in the body are relative to these two dates\.

Table 2:Headline results across the four experiments atN=200N=200\(planned probes/writes per experiment\) on a freshly\-provisioned MemClaw tenant\. Leakage carries two signals per probe: the authoritative*access*signal from𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id, and the secondary*discovery*signal from semantic search\. Counts in parentheses indicate the denominator the rate is over\. Each rate is followed by its95%95\\%Wilson score interval\. The GET\-by\-id tenant\-key rows measure tenant\-wide reachability under a tenant\-scoped credential and should be read as exposure under tenant authority, not by themselves as a sub\-tenant policy violation\. The sub\-tenant enforcement gap is established by the agent\-scoped probe in Table[3](https://arxiv.org/html/2606.24535#S8.T3): at measurement time, a trust\-11agent could𝙶𝙴𝚃\\mathtt\{GET\}a cross\-fleet row that the trust ladder should have denied; this was remediated on 2026\-05\-31 \(§[9\.1](https://arxiv.org/html/2606.24535#S9.SS1); re\-probe trust\-11cross\-fleet0/360/36\)\.ExperimentMetricValueLeakageprobes total \(planned / executed\)192192/192192tenant\-key GET exposure, GET\-by\-id \(ncross\-scope=164n\_\{\\text\{cross\-scope\}\}=164\)1\.000\\mathbf\{1\.000\}95% Wilson CI\[0\.977,1\.000\]\[0\.977,1\.000\]tenant\-key GET miss rate, GET\-by\-id \(nin\-scope=28n\_\{\\text\{in\-scope\}\}=28\)0\.0000\.00095% Wilson CI\[0\.000,0\.121\]\[0\.000,0\.121\]searchleak rate, semantic search \(ndeny=164n\_\{\\text\{deny\}\}=164\)0\.4390\.43995% Wilson CI\[0\.365,0\.516\]\[0\.365,0\.516\]searchmiss rate \(nallow=28n\_\{\\text\{allow\}\}=28\)0\.1430\.14395% Wilson CI\[0\.057,0\.315\]\[0\.057,0\.315\]access / search latency p50296296/726726msProvenancechain completeness \(depth=4=4,5050chains\)1\.000\\mathbf\{1\.000\}95% Wilson CI\[0\.929,1\.000\]\[0\.929,1\.000\]writer\-identity accuracy \(all chains\)1\.0001\.00095% Wilson CI\[0\.929,1\.000\]\[0\.929,1\.000\]per\-hop fetch latency p50 / p95 / p99291291/491491/1,0761\{,\}076msPropagationwrites succeeded \(planned=40=40\)4040visibility probes produced \(planned=200=200\)200200fleet\-sibling visibility \(nprobes=120n\_\{\\text\{probes\}\}=120\)0\.975\\mathbf\{0\.975\}95% Wilson CI\[0\.929,0\.991\]\[0\.929,0\.991\]cross\-fleet leak rate \(nprobes=80n\_\{\\text\{probes\}\}=80\)0\.000\\mathbf\{0\.000\}95% Wilson CI\[0\.000,0\.046\]\[0\.000,0\.046\]write→\\tovisible window p50 / p95 \(tight poll,88facts\)0\.830\.83/1\.631\.63sContradictionwrites succeeded \(planned=400=400\)194194detection rate, all fact\-runs \(n=200n=200\)0\.4900\.49095% Wilson CI\[0\.422,0\.559\]\[0\.422,0\.559\]detection rate, both writes admitted \(n=90n=90\)1\.000\\mathbf\{1\.000\}95% Wilson CI\[0\.959,1\.000\]\[0\.959,1\.000\]write latency p50 / p95 \(succeeded\)1,8401\{,\}840/4,8614\{,\}861mswrite latency p9919,31919\{,\}319ms
### 8\.1Leakage

Across192192probes spanning164164expected\-deny and2828expected\-allow combinations, the two\-signal measurement \(§[7](https://arxiv.org/html/2606.24535#S7)\) returns markedly different rates on the two axes; see Fig\.[2](https://arxiv.org/html/2606.24535#S8.F2)\. The headline finding is that*scope enforcement was bimodal at measurement time*\(the𝙶𝙴𝚃\\mathtt\{GET\}\-path gap was remediated the next day; §[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\):

- •On the tenant\-key access axis \(𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id with the probing tenant in the query string\), tenant\-key GET exposure was164/164=1\.000164/164=1\.000\(95% Wilson CI\[0\.977,1\.000\]\[0\.977,1\.000\]\) and the corresponding in\-scope miss rate was0/28=0\.0000/28=0\.000\. These bulk probes use a tenant\-scoped key, which is tenant\-wide by design, so this number is not by itself the sub\-tenant policy violation\. Rather, it shows that once a tenant\-authorized caller holds a𝚖𝚎𝚖𝚘𝚛𝚢​\_​𝚒𝚍\\mathtt\{memory\\\_id\}, the direct access path returns the row\. Whether fleet/agent scope is enforced for agent\-scoped callers is tested by the focused probe below, which at measurement time showed that sub\-tenant scope was not enforced on𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id\.
- •On the secondarydiscoveryaxis \(semantic search with the probing fleet in𝚏𝚕𝚎𝚎𝚝​\_​𝚒𝚍𝚜\\mathtt\{fleet\\\_ids\}\),search\_leak\_rate=72/164=0\.439=72/164=0\.439andsearch\_miss\_rate=4/28=0\.143=4/28=0\.143\. The search path*partially*honours the fleet filter — roughly44%44\\%of cross\-fleet probes still surfaced the row, and a seventh of same\-fleet probes missed it under embedding\-similarity ranking\.

A natural objection is that the access leak is merely an artifact of the tenant key carrying no agent identity — give the gateway an agent identity to filter on and the leak would close\. We tested that objection directly with the agent\-scoped probe \(§[7](https://arxiv.org/html/2606.24535#S7)\), and at measurement time it did not hold\. The gateway*does*resolve the agent identity for a𝚔𝚒𝚗𝚍=𝚊𝚐𝚎𝚗𝚝​\_​𝚔𝚎𝚢\\mathtt\{kind\{=\}agent\\\_key\}credential \(/whoamireturns the bound𝚊𝚐𝚎𝚗𝚝​\_​𝚒𝚍\\mathtt\{agent\\\_id\}; a tenant key returns𝚊𝚐𝚎𝚗𝚝​\_​𝚒𝚍=𝚗𝚞𝚕𝚕\\mathtt\{agent\\\_id\{=\}null\}\), yet𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id still returned cross\-fleet rows: an agent bound to𝚏𝚕𝚎𝚎𝚝​\-​𝟶\\mathtt\{fleet\\text\{\-\}0\}attrust=1\\text\{trust\}=1— below the trust\-22cross\-fleet\-read rung — successfully fetched a𝚏𝚕𝚎𝚎𝚝​\-​𝟷\\mathtt\{fleet\\text\{\-\}1\}row, while its same\-fleet control and the trust\-22credential behaved as expected \(Table[3](https://arxiv.org/html/2606.24535#S8.T3)\)\. Inspecting the handler confirmed the cause:𝙶𝙴𝚃/𝚖𝚎𝚖𝚘𝚛𝚒𝚎𝚜/\{𝚒𝚍\}\\mathtt\{GET\\ /memories/\\\{id\\\}\}checked only𝚎𝚗𝚏𝚘𝚛𝚌𝚎​\_​𝚛𝚎𝚊𝚍𝚊𝚋𝚕𝚎​\_​𝚝𝚎𝚗𝚊𝚗𝚝\\mathtt\{enforce\\\_readable\\\_tenant\}and𝚖𝚎𝚖𝚘𝚛𝚢\.𝚝𝚎𝚗𝚊𝚗𝚝\_𝚒𝚍==𝚝𝚎𝚗𝚊𝚗𝚝\_𝚒𝚍\\mathtt\{memory\.tenant\\\_id==tenant\\\_id\}; it never consulted the caller’s fleet, agent, the row’s visibility scope, or the trust level, so the resolved𝚊𝚐𝚎𝚗𝚝​\_​𝚒𝚍\\mathtt\{agent\\\_id\}was discarded\. The access leak was therefore a genuine*enforcement gap*on the𝙶𝙴𝚃\\mathtt\{GET\}path, not an authentication\-model artifact\. In the terms of §[3](https://arxiv.org/html/2606.24535#S3), the handler discharged only the tenant projection ofsis\_\{i\}, violatingInv\-Scopefor fleet\- and agent\-scoped rows — the measured leak was exactly the predicted violation\. We disclosed the gap; it was remediated server\-side during the study \(Remediation, §[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\)\.

Table 3:Agent\-scoped𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id probe,*as measured*\(2026\-05\-30\)\. The gateway resolves each agent’s identity \(confirmed via/whoami\); the documented trust ladder defines cross\-fleet read attrust≥2\\text\{trust\}\\geq 2\. At that time every probe returned the row \(HTTP200200\) — including the trust\-11cross\-fleet read the ladder should deny — because the handler checked only the tenant\.Since remediated:a scaled re\-probe \(2026\-05\-31,9696probes\) denies trust\-11cross\-fleet reads \(0/360/36, now HTTP404404\) and admits trust\-22\(36/3636/36\); see Remediation, §[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\.Access latency is tighter than search latency \(p50=296=296ms vs726726ms\), shown in Fig\.[3](https://arxiv.org/html/2606.24535#S8.F3), consistent with the access path being a direct primary\-key lookup while the search path runs an embedding\-similarity scan\.

![Refer to caption](https://arxiv.org/html/2606.24535v1/leakage_leakage_by_axis.png)Figure 2:Leakage envelope by measurement axis,*as measured*\(2026\-05\-30\)\. Theleak\_rate\(over expected\-deny probes\) is the security signal; themiss\_rate\(over expected\-allow probes\) is the availability signal\. Enforcement was bimodal\. The𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id tenant\-key axis returned every requested row to a tenant\-scoped caller \(tenant\-key exposure=1\.000=1\.000\), which is expected under tenant\-wide authority\. The sub\-tenant enforcement gap is shown by the agent\-scoped probe in Table[3](https://arxiv.org/html/2606.24535#S8.T3): a trust\-11agent could retrieve a cross\-fleet row that should have been denied\. The discovery path applied the fleet filter only partially \(search\_leak\_rate=0\.439=0\.439\) and missed a seventh of entitled probes under embedding\-similarity ranking\.![Refer to caption](https://arxiv.org/html/2606.24535v1/leakage_search_latency.png)Figure 3:Search\-latency distribution across the192192leakage probes\. Dashed and dotted vertical lines mark the p50 and p95 of the distribution\.
### 8\.2Provenance

We observed complete end\-to\-end chain reconstruction with sub\-second per\-hop latency\. All200200planned writes landed and all5050depth\-four chains reconstructed: completeness, writer\-identity accuracy, and depth\-fidelity were each1\.001\.00, as summarized in Table[2](https://arxiv.org/html/2606.24535#S8.T2)\. The harness walked each four\-hop derivation chain viametadata\.derived\_fromat p50=291=291ms and p95=491=491ms per fetch \(median sum\-per\-chain≈1\.2\\approx 1\.2s, p99=1\.1=1\.1s\)\. In every chain the fetched ancestor’sagent\_idmatched the planned writer, demonstrating that the server preserves identity through the storage round\-trip\.

Reaching complete reconstruction required pacing writes beneath MemClaw’s per\-tenant write ceiling\. The server caps writes at1010per second per tenant \(HTTP429429, “1010per11second”\); because provenance writes are sequential within a chain, an unthrottled run whose concurrency bursts past that ceiling aborts the remainder of any chain whose intermediate write is rejected\. Throttling the client to88writes/second — below the ceiling — eliminates the rejections without altering the workload, and is what separates the complete reconstruction reported here from earlier runs that lost chains to rate\-limited writes\. The per\-fetch latency distribution is shown in Fig\.[4](https://arxiv.org/html/2606.24535#S8.F4)\.

![Refer to caption](https://arxiv.org/html/2606.24535v1/provenance_fetch_latency.png)Figure 4:Per\-hop fetch\-latency distribution across all provenance chain walks\. The p50 of291291ms and p95 of491491ms support chain reconstruction at interactive latencies even at depth four \(p99=1\.1=1\.1s\)\.
### 8\.3Propagation

All4040planned writes landed and all200200downstream visibility probes fired\. Fleet\-sibling visibility was𝟏𝟏𝟕/𝟏𝟐𝟎=0\.975\\mathbf\{117/120=0\.975\}\(95%95\\%Wilson score interval\[0\.929,0\.991\]\[0\.929,0\.991\]\) across intra\-fleet probes, with zero cross\-fleet leaks across𝟖𝟎\\mathbf\{80\}foreign\-fleet probes \(leak\_rate=0/80=0/80,95%95\\%Wilson CI\[0\.000,0\.046\]\[0\.000,0\.046\]\)\. The three misses are siblings whose canary never surfaced before the3030\-second poll deadline — a retrieval\-recall effect \(with many similar facts in the fleet, the target can rank below the top\-kk\), not a propagation failure\.

We measure the write\-to\-visible window separately, on88dedicated facts each polled tightly from write completion at250250ms granularity \(§[7](https://arxiv.org/html/2606.24535#S7)\)\. Underwrite\_mode = strongthe row is searchable the*instant*the write returns: all88facts surfaced on the poller’s*first*search after the write \(𝚙𝚘𝚕𝚕​\_​𝚌𝚘𝚞𝚗𝚝=1\\mathtt\{poll\\\_count\}=1\), with a median time\-to\-visible of0\.830\.83s and a max of1\.971\.97s — itself essentially one search round\-trip, indistinguishable from the search\-latency floor \(leakage search p50≈0\.73\\approx 0\.73s\)\. Strong\-mode enrichment is therefore*synchronous*: its cost is paid in the write latency \(p50≈1\.8\\approx 1\.8s, §[8](https://arxiv.org/html/2606.24535#S8)\), and there is no measurable post\-write eventual\-consistency tail\.

This revises an earlier, naive measurement\. Seeding every fact and*then*draining all probes through a concurrency gate makes a probe’s first/𝚜𝚎𝚊𝚛𝚌𝚑\\mathtt\{/search\}land long after the row is already searchable; that schedule reported a p50 of tens of seconds, which grows with probe count\. It is a probe\-scheduling artifact, not server behaviour — which is precisely why we measure the window with the dedicated tight\-polling phase instead \(§[10](https://arxiv.org/html/2606.24535#S10)\)\. The rate phase’s fleet\-sibling probes still poll/searchup to a3030\-second deadline \(cross\-fleet readers issue a single attempt\), but only their visibility/leak*outcomes*are used, not their latency\. Fig\.[5](https://arxiv.org/html/2606.24535#S8.F5)contrasts the intra\-fleet and cross\-fleet visibility rates side by side, and Fig\.[6](https://arxiv.org/html/2606.24535#S8.F6)shows the window\-phase time\-to\-visibility distribution\.

![Refer to caption](https://arxiv.org/html/2606.24535v1/propagation_visibility_by_relation.png)Figure 5:Visibility rate by reader relation\. Fleet siblings \(intra\-fleet readers\) saw nearly every fact \(117/120117/120\); the three misses are writes whose canary ranked below the top\-kkunder embedding\-similarity search \(a recall effect, not a propagation failure\)\. Foreign\-fleet readers \(same tenant, different fleet\) saw none \(0/800/80\)\. Annotations show \(visible / total\) probe counts per axis\.![Refer to caption](https://arxiv.org/html/2606.24535v1/propagation_time_to_visibility.png)Figure 6:Write\-to\-visible window from the dedicated window phase:88facts, each polled tightly from write completion at250250ms granularity\. Under strong write mode every fact surfaced on the poller’s first search \(p50=0\.83=0\.83s, max1\.971\.97s\) — one search round\-trip, i\.e\. effectively immediate\. This isolates the server’s single\-write consistency window from the probe\-scheduling inflation a batched schedule exhibits \(§[10](https://arxiv.org/html/2606.24535#S10)\)\.
### 8\.4Contradiction

Measured correctly, the contradiction primitive*works*\. Conditional on both contradictory writes being admitted, supersession was established ineverycase —90/90=1\.00090/90=1\.000\(95%95\\%Wilson CI\[0\.959,1\.000\]\[0\.959,1\.000\]\): a post\-commit re\-fetch found the newer row carryingsupersedes\_idpointing at the older, and the older flipped tooutdated, within≈6\\approx\\\!6s of the write\. Overalldetection\_rateis98/200=0\.49098/200=0\.490; the gap from1\.01\.0is entirely an*admission*effect, not a detector failure \(see below\)\.

Two corrections to an earlier, mis\-measured version of this experiment underlie the result\. First, detection is*post\-commit and asynchronous*:supersedes\_idis set after the write response returns, so reading it from the synchronous response \(as we first did\) reports a spurious0/2000/200\. The re\-fetch \(§[7](https://arxiv.org/html/2606.24535#S7)\) is what surfaces the true outcome\. Second, the structural detector only runs for predicates the server treats as single\-valued; our earlierdeployment\_regionwas not one, so the RDF path was silently skipped\. Using a single\-valued predicate \(region,runs\_on, …\) and re\-fetching post\-settle fixes both\.

The0\.4900\.490ceiling is set by write*admission*:206/400206/400writes were rejected409409by the synchronous dedup gate before reaching the \(post\-commit\) detector, so9090fact\-runs had both writes land\. The rejections fall roughly evenly across the first and second write of a pair and are dominated by exact\-content duplicates — partly the genuine dedup\-pre\-empts\-contradiction effect of §[9](https://arxiv.org/html/2606.24535#S9)\(a contradiction phrased as “XXisAA” vs “XXisBB” is near\-identical text\), partly limited prose diversity in our workload generator\. We do not cleanly separate the two; the robust claim is the conditional one:*when both writes are admitted, supersession is correct90/9090/90*\. Admission is stochastic — concurrent writes race at the dedup gate and content is nonce\-salted per run — so counts vary run\-to\-run around a stable rate: four independentN=200N\{=\}200runs gave both\-admitted9090–9191and detections9696–100100\(detection\_rate0\.480\.48–0\.500\.50\)\.333The run of record’s both\-admitted=90=90is exactly2×2\\timestheN=100N\{=\}100run’s4545; this is coincidence, not a scaled figure — sibling runs give9191, and all fiveN=200N\{=\}200/N=100N\{=\}100contradiction traces are committed undertraces/for direct per\-write verification\.The overall detection count \(9898\) slightly exceeds both\-admitted \(9090\) because a fact’s sequential and concurrent scenarios share asubject\_entity\_idand predicate, so the single admitted write in one scenario can supersede the admitted write in the other:88such cross\-scenario detections \(44fact pairs\) arise where each scenario admitted only one of its two writes\.stale\_read\_ratewas0/2000/200\(no fact\-run returned two active rows\), consistent with the older row being markedoutdatedon resolution; with search visibility now measured at∼1\\sim\\\!1s \(§[8](https://arxiv.org/html/2606.24535#S8)\), well inside the2020s settle, this signal is no longer materially confounded by search lag, though the GET\-by\-id re\-fetch remains the primary one\.

Write\-latency p50 of1,8401\{,\}840ms and p95 of4,8614\{,\}861ms \(p9919,31919\{,\}319ms, across the194194writes that completed\) reflect the cost of the full enrichment pipeline \(write\_mode = strong\); the heavier p95/p99 tail relative to the smaller run is queueing when more writes contend for the synchronous pipeline at once\. Because contradiction detection is post\-commit and asynchronous, it adds nothing to this synchronous write latency\. Fig\.[7](https://arxiv.org/html/2606.24535#S8.F7)shows the distribution\.

![Refer to caption](https://arxiv.org/html/2606.24535v1/contradiction_write_latency.png)Figure 7:Write\-latency distribution underwrite\_mode = strongfor the contradiction experiment, in milliseconds \(p501,8401\{,\}840, p954,8614\{,\}861; dashed/dotted markers\)\. Contradiction detection runs post\-commit and asynchronously, so it contributes nothing to this synchronous write latency: the distribution characterises the steady\-state strong\-mode write path, with the supersession established afterward \(≈6\\approx\\\!6s, §[8](https://arxiv.org/html/2606.24535#S8)\)\.

## 9Discussion and Findings

The empirical study surfaces three architecturally significant findings about production memory infrastructure, independent of the headline rate metrics\.

### 9\.1Scope Enforcement Was Bimodal \(GET\-Path Gap Remediated\)

The leakage experiment surfaces a structural asymmetry in how scope is enforced\. Tenant boundaries are enforced uniformly: cross\-tenant requests are rejected on both𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id and𝙿𝙾𝚂𝚃\\mathtt\{POST\}\-search paths \(the leakage rate measurements above were collected within a single tenant for that reason — cross\-tenant probes do not reach the read handlers at all\)\.*Sub\-tenant*scope — fleet and agent — was, at measurement time, enforced only on the search path \(and there only partially\); the𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id path is addressed by the remediation below\.

At measurement time, direct𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id returned a row to any tenant\-authorized caller who presented the correct𝚝𝚎𝚗𝚊𝚗𝚝​\_​𝚒𝚍\\mathtt\{tenant\\\_id\}, regardless of the originating fleet or writer\. Crucially, this held even when the caller presented an agent\-scoped credential whose identity the gateway resolves \(§[8](https://arxiv.org/html/2606.24535#S8), Table[3](https://arxiv.org/html/2606.24535#S8.T3)\): the𝚐𝚎𝚝​\_​𝚖𝚎𝚖𝚘𝚛𝚢\\mathtt\{get\\\_memory\}handler enforced only the tenant predicate \(𝚎𝚗𝚏𝚘𝚛𝚌𝚎​\_​𝚛𝚎𝚊𝚍𝚊𝚋𝚕𝚎​\_​𝚝𝚎𝚗𝚊𝚗𝚝\\mathtt\{enforce\\\_readable\\\_tenant\}plus𝚖𝚎𝚖𝚘𝚛𝚢\.𝚝𝚎𝚗𝚊𝚗𝚝\_𝚒𝚍==𝚝𝚎𝚗𝚊𝚗𝚝\_𝚒𝚍\\mathtt\{memory\.tenant\\\_id==tenant\\\_id\}\) and never consulted the caller’s fleet/agent, the row’s visibility scope, or the trust level — so the agent identity, present in\-request as𝚇​\-​𝙰𝚐𝚎𝚗𝚝​\-​𝙸𝙳\\mathtt\{X\\text\{\-\}Agent\\text\{\-\}ID\}, was simply discarded\. Search, by contrast, accepts𝚏𝚕𝚎𝚎𝚝​\_​𝚒𝚍𝚜\\mathtt\{fleet\\\_ids\}in the request body and applies it as a filter, but the filter coexists with embedding\-similarity ranking:43\.9%43\.9\\%\(72/16472/164\) of cross\-fleet probes still surfaced the row\.

We initially conjectured this asymmetry was a property of the authentication model rather than a defect — that agent\-scoped keys would let the gateway resolve a requesting agent’s fleet and apply scope to𝙶𝙴𝚃\\mathtt\{GET\}as it does to search\. The probe in §[8](https://arxiv.org/html/2606.24535#S8)refuted that conjecture: the identity*was*resolved and then ignored by the handler, so a trust\-11agent read a cross\-fleet row the trust ladder should deny\. It was therefore a genuine enforcement gap — a violation ofInv\-Scope\(§[3](https://arxiv.org/html/2606.24535#S3)\) — not a credential limitation, and while it stood, the propagation of𝚖𝚎𝚖𝚘𝚛𝚢​\_​𝚒𝚍\\mathtt\{memory\\\_id\}values across fleet boundaries was itself the de\-facto capability boundary\.

#### Remediation\.

We disclosed the gap; it was fixed server\-side during the study\. A scaled re\-probe on 2026\-05\-31 —9696𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id probes across four fleets and both trust levels, with each agent using its own agent\-scoped key, committed undertraces/— confirms the𝚐𝚎𝚝​\_​𝚖𝚎𝚖𝚘𝚛𝚢\\mathtt\{get\\\_memory\}handler now applies exactly the fleet/agent/scope filter the search path already carried: trust\-11cross\-fleet reads are denied \(0/360/36, 95% Wilson\[0\.000,0\.096\]\[0\.000,0\.096\], returned as𝟺𝟶𝟺\\mathtt\{404\}so the row’s existence is not disclosed\), trust\-22cross\-fleet reads are admitted by the ladder \(36/3636/36\), and same\-fleet controls pass \(12/1212/12\); total leaks0/960/96\. The bulk164/164164/164access rate \(§[8](https://arxiv.org/html/2606.24535#S8)\) was collected with a*tenant*\-scoped key, which is tenant\-wide by design and never subject to sub\-tenant scope; with agent\-scoped reads now enforced, the credential\-independence we originally observed no longer holds\. We name the resulting asymmetry plainly: the bulk164/164164/164\(tenant key, 2026\-05\-30\) and the0/360/36remediation re\-probe \(2026\-05\-31\) are both committed traces \(traces/\), but the agent\-scoped*open*state — the surprising part — is no longer reproducible against the live service, so it rests on the dated probe \(Table[3](https://arxiv.org/html/2606.24535#S8.T3)\) and the𝚐𝚎𝚝​\_​𝚖𝚎𝚖𝚘𝚛𝚢\\mathtt\{get\\\_memory\}handler reading rather than a replayable trace\. The verifiable artifacts thus attest the tenant\-key behaviour and the fix; the transient agent\-scoped gap is dated and inspected, not replayable\. The episode is itself a result: the formalism flagged a concreteInv\-Scopeviolation, the harness localised it to one handler, and the remediation was precisely the predicate the search path already carried — evidence that the failure\-mode taxonomy points at fixable, well\-localised defects rather than diffuse ones\.

### 9\.2Deduplication Starves Contradiction Detection

The contradiction detector itself is sound: conditional on both writes being admitted, it superseded correctly in every case \(90/9090/90, §[8](https://arxiv.org/html/2606.24535#S8)\)\. The architectural issue is that two mechanisms on the write path interact badly\. A semantic near\-duplicate detector evaluates an incoming write synchronously,*pre\-commit*, returning409409when embedding similarity exceeds a threshold\. The contradiction detector evaluates RDF\-triple compatibility and setssupersedes\_id— but it runs*post\-commit and asynchronously*\. So the synchronous gate can reject a write before the asynchronous detector ever sees it\. The pathological case is intrinsic: a contradiction phrased naturally \(“XXisAA” then “XXisBB”\) 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\. \(This is also why the detector reads as a “null” under naive measurement — it never receives the input, andsupersedes\_idis async besides\.\)

We argue this ordering is incorrect: a contradiction is precisely a near\-duplicate with a different assertive object, and conflating the two collapses two distinct architectural primitives into one error code\. We propose either \(a\) reordering the pipeline so that structural contradiction detection runs first when a write carries an RDF triple, or \(b\) widening the near\-duplicate threshold for writes that carry an RDF triple, since the structural signal is the more discriminating one\.

### 9\.3Cross\-Agent Propagation Is Privilege\-Gated

ThePOST /memories/redistributeendpoint requires the requesting agent to holdtrust\_level≥3\\text\{trust\\\_level\}\\geq 3, placing cross\-agent memory propagation behind an administrative gate\. From the perspective of the architecture in §5, this conflates two policy concerns:*can this agent propagate fleet\-shared knowledge to a sibling within its own fleet?*and*can this agent administratively re\-home memories arbitrarily?*The first is a normal operation in any non\-trivial multi\-agent workflow; the second is a privileged migration\.

We argue that fleet\-scoped propagation between sibling agents inside a fleet should be available at the same trust level as fleet\-scoped writes, and that the higher trust gate should apply only to cross\-fleet or cross\-scope re\-homing\. The current production behaviour is consistent with treating all redistributes as administrative migrations; under a governed\-memory architecture the propagation primitive should expose a finer\-grained policy surface\.

### 9\.4The Consistency Cost Is Paid at Write Time, Not Read Time

Measured with tight per\-fact polling*at low contention*\(the window phase polls one fact at a time; §[8](https://arxiv.org/html/2606.24535#S8)\), the write\-to\-visible window underwrite\_mode = strongis effectively zero: a fleet sibling’s first search after the write already returns the row \(p50≈0\.8\\approx 0\.8s — one search round\-trip\)\. Strong\-mode enrichment is*synchronous*, so the consistency cost is paid in the write latency, not as a post\-write read\-visibility lag — but that cost is load\-dependent: at the sustained write concurrency of the contradiction run the write\-latency p99 reaches1919s \(§[8](https://arxiv.org/html/2606.24535#S8)\), against a p50 of≈1\.8\\approx\\\!1\.8s\. The window phase, deliberately uncontended, measures the visibility floor; the write\-latency tail is the price the same consistency guarantee charges under load\.

This matters methodologically as much as architecturally\. A naive measurement that seeds every write and*then*drains read probes reports a window of tens of seconds that*grows with probe count*— the entire figure is harness scheduling, not server behaviour, because a drained probe’s first look lands long after the row is already searchable\. \(An earlier version of this work reported exactly such a figure\.\) Quantifying a service’s true consistency window therefore requires polling each write immediately and continuously, decoupled from the rate workload; otherwise one measures one’s own client\. The architectural takeaway is robust to that subtlety: the placement of enrichment on the write path versus the read path is a first\-order design choice, and a service that enriches synchronously \(as MemClaw does under strong mode\) buys immediate read consistency at the price of write latency — the budget a multi\-agent orchestrator must plan against is the write, not a visibility tail\.

## 10Limitations

Several limitations bound the scope of the empirical claims in §[8](https://arxiv.org/html/2606.24535#S8)\.

#### Self\-evaluation\.

ArgusFleet and MemClaw are built by the same group; this is an evaluation of our own production service, not an independent audit\. We mitigate the obvious bias by reporting the unflattering results prominently — the𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id enforcement gap \(disclosed, since remediated\) and the dedup/contradiction pipeline\-ordering issue — and by deriving every figure from a committed JSONL trace\. Reporting a gap in one’s own service and then its fix is an obvious place for bias to hide; we counter it by committing the re\-probe trace, not just asserting the remediation\. An independent replication, which the open harness enables against any wire\-compatible service, would carry more weight than our own numbers\.

#### Agent\-scope probe is focused, not exhaustive\.

The bulk leakage rates were collected with a tenant\-scoped key \(tenant\-wide by design\); the*sub\-tenant*question was settled with agent\-scoped credentials\. The original observation was a small focused probe \(Table[3](https://arxiv.org/html/2606.24535#S8.T3)\); the post\-remediation re\-probe is larger \(9696𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id probes across four fleets and both trust levels, committed undertraces/\) and finds the gap closed \(0/360/36trust\-11cross\-fleet, §[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\)\. Two caveats follow from the timeline: the open state was observed at one point and is no longer reproducible against the live service, so the as\-measured gap rests on the dated observation plus the𝚐𝚎𝚝​\_​𝚖𝚎𝚖𝚘𝚛𝚢\\mathtt\{get\\\_memory\}handler reading, while the remediation rests on the committed re\-probe; and a fuller adversarial matrix \(many agents, scopes, visibility levels\) would harden both\. Cross\-*tenant*isolation remains untested for the separate reason below\.

#### Staleness\-after\-supersession is only partially measured\.

The contradiction experiment establishes the*resolution*side of staleness: when both writes are admitted the older row flips tooutdatedand the newer carriessupersedes\_id\(§[8](https://arxiv.org/html/2606.24535#S8),90/9090/90\), andstale\_read\_rate=0/200\\textsc\{stale\\\_read\\\_rate\}=0/200found no fact\-run serving two simultaneously\-active rows\. But the stale\-read check rides on semantic search, whose enrichment window we now measure directly at∼1\\sim\\\!1s \(§[8](https://arxiv.org/html/2606.24535#S8)\) — well within the2020\-second settle — so a0there reflects correct resolution rather than search lag\. \(An earlier draft, which inferred the window from the batched probe schedule rather than measuring it, could not separate the two\.\) The GET\-by\-id re\-fetch remains the primary signal; theactive\-search exclusion now corroborates it instead of being confounded by lag\.

#### Single tenant\.

All measurements were collected from a single MemClaw tenant, freshly provisioned\. The cross\-*tenant*leakage probe surface, which would exercise the strongest governance claim, is not measurable in this configuration\. The harness supports multi\-tenant configuration via theMEMCLAW\_TENANT\_IDlist and we expect cross\-tenant probes to be uniformly rejected by the gateway’s tenant enforcement \(§[9\.1](https://arxiv.org/html/2606.24535#S9.SS1)\); confirming that empirically remains future work\.

#### Workload scale\.

We report200200trials per experiment\. Theleak\_rateWilson interval at164/164164/164is\[0\.977,1\.000\]\[0\.977,1\.000\]; thecross\-fleet leak rateat0/800/80in propagation is bounded above by approximately0\.0460\.046\. Stronger claims would benefit from a further order of magnitude more probes and probes constructed adversarially rather than via deterministic plan generation\.

#### Time\-to\-visibility requires decoupled measurement\.

Time\-to\-visibility cannot be read off the rate\-phase probes: seeding every write and then draining all probes through a concurrency gate makes each probe’s first/𝚜𝚎𝚊𝚛𝚌𝚑\\mathtt\{/search\}land after the row is already searchable, so the recorded latency measures harness scheduling and*grows with probe count*\(an earlier version of this work reported a p50 of tens of seconds for exactly this reason\)\. We therefore measure the window on a small set of facts polled immediately and continuously from write completion \(§[7](https://arxiv.org/html/2606.24535#S7)\), one at a time so the polls stay under the/𝚜𝚎𝚊𝚛𝚌𝚑\\mathtt\{/search\}budget; under strong mode this yields a p50 of∼0\.8\\sim\\\!0\.8s \(§[8](https://arxiv.org/html/2606.24535#S8)\)\. The residual limitation is granularity and scale: the window is measured at250250ms resolution on88facts, so it resolves “effectively immediate” but not a sub\-250250ms value, and a larger, multi\-region sweep would sharpen the tail and test whether the synchronous\-enrichment behaviour holds under sustained load\.

#### 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\.

## 11Conclusion

Taken together, the paper delivers the three contributions introduced in §1\.1: a formal framing of fleet memory as governed operational state, an implementation and evaluation harness for exercising the proposed primitives, and a live\-service measurement showing both where those primitives hold and where production enforcement and pipeline ordering can fail\.

We introduced a systems architecture for governed shared memory in multi\-agent LLM environments, instantiated it in MemClaw, and evaluated the resulting primitives using ArgusFleet, a reproducible harness that exercises the four governance failure modes of §[4](https://arxiv.org/html/2606.24535#S4)as four experiments against a live memory service, reporting five metric axes: governance correctness, contradiction handling, provenance reconstruction, and cross\-agent visibility — one per failure mode — plus*retrieval recall*as an orthogonal availability control sharing its probe set with the leakage experiment\.

The empirical study shows that provenance chains reconstruct completely \(50/5050/50\) at sub\-second per\-hop latency \(p50≈291\\approx 291ms at depth four\) once writes are paced below the server’s rate ceiling, that cross\-fleet propagation is correct on117/120117/120intra\-fleet probes \(0\.9750\.975\) with zero leaks across8080foreign\-fleet probes, and that — measured by tight per\-fact polling at low load — the write\-to\-visible window under strong write mode is effectively immediate \(p50≈0\.8\\approx 0\.8s, one search round\-trip\), with the consistency cost paid in write latency \(which itself develops a heavy tail, p99≈19\\approx 19s, under sustained write contention\) rather than as a read\-visibility lag\. It also surfaces three architectural observations: scope enforcement was bimodal at measurement time — tenant\-level isolation enforced on every path, sub\-tenant scope enforced partially on the search path and not at all on direct𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id \(the read handler discarded even a resolved agent identity\); we disclosed this and it was remediated server\-side during the study, with a committed re\-probe confirming agent\-scoped𝙶𝙴𝚃\\mathtt\{GET\}\-by\-id now enforces fleet scope and the trust ladder; contradiction supersession is correct when both writes are admitted \(90/9090/90\), but a synchronous dedup gate pre\-empts near\-identically phrased contradictory writes before the asynchronous detector runs; and cross\-agent memory re\-homing is privilege\-gated in a way that conflates fleet\-internal propagation with administrative migration\.

We argued throughout that AI memory is evolving from a context\-window problem into a distributed systems problem requiring governance, synchronization, temporal correctness, provenance, and scoped access control\. The empirical results support this framing: in production memory infrastructure, the primitives that matter for correctness are precisely the ones inherited from distributed systems — consistency windows, identity preservation through round\-trips, ordering of pipeline stages, and the privilege model attached to propagation\. As AI systems continue shifting from isolated assistants toward coordinated fleets of agents, governed shared memory becomes a foundational infrastructure layer whose architectural choices have measurable consequences for the workflows built on top\.

## References

- \[1\]P\. Chhikara, D\. Khant, S\. Aryan, T\. Singh, and D\. Yadav\(2025\)Mem0: building production\-ready AI agents with scalable long\-term memory\.External Links:2504\.19413,[Link](https://arxiv.org/abs/2504.19413)Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p1.1)\.
- \[2\]J\. C\. Corbett, J\. Dean, M\. Epstein, A\. Fikes, C\. Frost, J\. J\. Furman, S\. Ghemawat, A\. Gubarev, C\. Heiser, P\. Hochschild, W\. Hsieh, S\. Kanthak, E\. Kogan, H\. Li, A\. Lloyd, S\. Melnik, D\. Mwaura, D\. Nagle, S\. Quinlan, R\. Rao, L\. Rolig, Y\. Saito, M\. Szymaniak, C\. Taylor, R\. Wang, and D\. Woodford\(2013\-08\)Spanner: google’s globally distributed database\.ACM Trans\. Comput\. Syst\.31\(3\)\.External Links:ISSN 0734\-2071,[Link](https://doi.org/10.1145/2491245),[Document](https://dx.doi.org/10.1145/2491245)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[3\]M\. Costa, B\. Köpf, A\. Kolluri, A\. Paverd, M\. Russinovich, A\. Salem, S\. Tople, L\. Wutschitz, and S\. Zanella\-Béguelin\(2025\)Securing AI agents with information\-flow control\.External Links:2505\.23643,[Link](https://arxiv.org/abs/2505.23643)Cited by:[§2\.4](https://arxiv.org/html/2606.24535#S2.SS4.p1.4)\.
- \[4\]E\. Debenedetti, I\. Shumailov, T\. Fan, J\. Hayes, N\. Carlini, D\. Fabian, C\. Kern, C\. Shi, A\. Terzis, and F\. Tramèr\(2025\)Defeating prompt injections by design\.Note:arXiv:2503\.18813External Links:2503\.18813Cited by:[§2\.4](https://arxiv.org/html/2606.24535#S2.SS4.p1.4)\.
- \[5\]G\. DeCandia, D\. Hastorun, M\. Jampani, G\. Kakulapati, A\. Lakshman, A\. Pilchin, S\. Sivasubramanian, P\. Vosshall, and W\. Vogels\(2007\)Dynamo: amazon’s highly available key\-value store\.ACM SIGOPS Operating Systems Review41\(6\),pp\. 205–220\.External Links:[Document](https://dx.doi.org/10.1145/1294261.1294281)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[6\]V\. C\. Hu, D\. Ferraiolo, R\. Kuhn, A\. Schnitzer, K\. Sandlin, R\. Miller, and K\. Scarfone\(2014\)Guide to attribute based access control \(ABAC\) definition and considerations\.NIST Special PublicationTechnical Report800\-162,National Institute of Standards and Technology\.External Links:[Document](https://dx.doi.org/10.6028/NIST.SP.800-162)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[7\]L\. Lamport\(1978\)Time, clocks, and the ordering of events in a distributed system\.Communications of the ACM21\(7\),pp\. 558–565\.External Links:[Document](https://dx.doi.org/10.1145/359545.359563)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[8\]LangChain\(2024\)LangMem: long\-term memory for LLM agents\.Note:[https://langchain\-ai\.github\.io/langmem/](https://langchain-ai.github.io/langmem/)Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p1.1)\.
- \[9\]P\. Lewis, E\. Perez, A\. Piktus, F\. Petroni, V\. Karpukhin, N\. Goyal, H\. Küttler, M\. Lewis, W\. Yih, T\. Rocktäschel, S\. Riedel, and D\. Kiela\(2020\)Retrieval\-augmented generation for knowledge\-intensive NLP tasks\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:2005\.11401Cited by:[§2\.1](https://arxiv.org/html/2606.24535#S2.SS1.p1.1)\.
- \[10\]J\. Liu, D\. Zhu, Z\. Bai, Y\. He, H\. Liao, H\. Que, Z\. Wang, C\. Zhang, G\. Zhang, J\. Zhang, Y\. Zhang, Z\. Chen, H\. Guo, S\. Li, Z\. Liu, Y\. Shan, Y\. Song, J\. Tian, W\. Wu, Z\. Zhou, R\. Zhu, J\. Feng, Y\. Gao, S\. He, Z\. Li, T\. Liu, F\. Meng, W\. Su, Y\. Tan, Z\. Wang, J\. Yang, W\. Ye, B\. Zheng, W\. Zhou, W\. Huang, S\. Li, and Z\. Zhang\(2025\)A comprehensive survey on long context language modeling\.External Links:2503\.17407,[Link](https://arxiv.org/abs/2503.17407)Cited by:[§2\.1](https://arxiv.org/html/2606.24535#S2.SS1.p1.1)\.
- \[11\]Y\. Margalit, E\. Avram, R\. Taig, O\. Margalit, and N\. Cohen\-Inger\(2026\)PeerRank: autonomous LLM evaluation through web\-grounded, bias\-controlled peer review\.External Links:2602\.02589,[Link](https://arxiv.org/abs/2602.02589)Cited by:[§2\.4](https://arxiv.org/html/2606.24535#S2.SS4.p2.1)\.
- \[12\]N\. Mireshghallah, H\. Kim, X\. Zhou, Y\. Tsvetkov, M\. Sap, R\. Shokri, and Y\. Choi\(2024\)Can LLMs keep a secret? testing privacy implications of language models via contextual integrity theory\.External Links:2310\.17884,[Link](https://arxiv.org/abs/2310.17884)Cited by:[§2\.4](https://arxiv.org/html/2606.24535#S2.SS4.p1.4)\.
- \[13\]C\. Packer, S\. Wooders, K\. Lin, V\. Fang, S\. G\. Patil, I\. Stoica, and J\. E\. Gonzalez\(2023\)MemGPT: towards LLMs as operating systems\.Note:arXiv:2310\.08560External Links:2310\.08560Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p1.1)\.
- \[14\]P\. Rasmussen, P\. Paliychuk, T\. Beauvais, J\. Ryan, and D\. Chalef\(2025\)Zep: a temporal knowledge graph architecture for agent memory\.Note:arXiv:2501\.13956External Links:2501\.13956Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p1.1)\.
- \[15\]A\. Rezazadeh, Z\. Li, A\. Lou, Y\. Zhao, W\. Wei, and Y\. Bao\(2025\)Collaborative memory: multi\-user memory sharing in LLM agents with dynamic access control\.Note:arXiv:2505\.18279External Links:2505\.18279Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p2.2)\.
- \[16\]R\. S\. Sandhu, E\. J\. Coyne, H\. L\. Feinstein, and C\. E\. Youman\(1996\)Role\-based access control models\.IEEE Computer29\(2\),pp\. 38–47\.External Links:[Document](https://dx.doi.org/10.1109/2.485845)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[17\]M\. Shapiro, N\. Preguiça, C\. Baquero, and M\. Zawirski\(2011\)Conflict\-free replicated data types\.InSymposium on Self\-Stabilizing Systems \(SSS\),Lecture Notes in Computer Science, Vol\.6976,pp\. 386–400\.External Links:[Document](https://dx.doi.org/10.1007/978-3-642-24550-3%5F29)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[18\]D\. B\. Terry, M\. M\. Theimer, K\. Petersen, A\. J\. Demers, M\. J\. Spreitzer, and C\. H\. Hauser\(1995\)Managing update conflicts in Bayou, a weakly connected replicated storage system\.InACM Symposium on Operating Systems Principles \(SOSP\),pp\. 172–182\.External Links:[Document](https://dx.doi.org/10.1145/224056.224070)Cited by:[§2\.3](https://arxiv.org/html/2606.24535#S2.SS3.p1.1)\.
- \[19\]B\. Wang, W\. He, S\. Zeng, Z\. Xiang, Y\. Xing, J\. Tang, and P\. He\(2025\)Unveiling privacy risks in LLM agent memory\.External Links:2502\.13172,[Link](https://arxiv.org/abs/2502.13172)Cited by:[§2\.4](https://arxiv.org/html/2606.24535#S2.SS4.p1.4)\.
- \[20\]Y\. Wang and X\. Chen\(2025\)MIRIX: multi\-agent memory system for LLM\-based agents\.Note:arXiv:2507\.07957External Links:2507\.07957Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p2.2)\.
- \[21\]Q\. Wu, G\. Bansal, J\. Zhang, Y\. Wu, B\. Li, E\. Zhu, L\. Jiang, X\. Zhang, S\. Zhang, J\. Liu, A\. H\. Awadallah, R\. W\. White, D\. Burger, and C\. Wang\(2023\)AutoGen: enabling next\-gen LLM applications via multi\-agent conversation\.External Links:2308\.08155,[Link](https://arxiv.org/abs/2308.08155)Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p1.1)\.
- \[22\]W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. Zhang\(2025\)A\-MEM: agentic memory for LLM agents\.Note:arXiv:2502\.12110External Links:2502\.12110Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p1.1)\.
- \[23\]G\. Zhang, M\. Fu, G\. Wan, M\. Yu, K\. Wang, and S\. Yan\(2025\)G\-Memory: tracing hierarchical memory for multi\-agent systems\.External Links:2506\.07398,[Link](https://arxiv.org/abs/2506.07398)Cited by:[§2\.2](https://arxiv.org/html/2606.24535#S2.SS2.p2.2)\.