Kernel-Managed Shared Memory for System-Wide Personalization

# Kernel-Managed Shared Memory for System-Wide Personalization
Source: [https://arxiv.org/html/2609.10144](https://arxiv.org/html/2609.10144)
\\workshoptitle

Ryan LumAffiliation:Department of Computer ScienceAffiliation:Rutgers UniversityAffiliation:Piscataway, NJ 08854Email:[rkl49@scarletmail\.rutgers\.edu](mailto:)Yongfeng ZhangAffiliation:Department of Computer ScienceAffiliation:Rutgers UniversityAffiliation:Piscataway, NJ 08854Email:[yongfeng\.zhang@rutgers\.edu](mailto:)

###### Abstract

AI systems become more useful when they can adapt to the people using them, but in multi\-agent systems, useful context learned by one agent often remains unavailable to others\. We present kernel\-managed shared memory, a system\-level abstraction in which specialized agents write structured, tagged memories while the agent\-system kernel – not individual agents – governs retrieval, privacy enforcement, and prompt injection\. We implement and evaluate this design on AIOS and compare it against three alternatives across three assistant models \(GPT\-4o, Llama\-3\.1:8B, Qwen\-2\.5:7B\) and 1,800 total trials\. Against an unmanaged external memory backend \(Mem0\) using identical underlying storage, kernel\-managed retrieval and injection improve personalization scores by2\.42\.4–4\.04\.0points on a 5\-point scale \(e\.g\.,→4\.691\.05\\\!\\to\\\!4\.69profile usage on GPT\-4o\), with every comparison significant atp<10−18p<10^\{\-18\}\. Against standard retrieval\-augmented injection, gains are similarly large and consistent across all three models\. Against full, unfiltered context concatenation – a soft ceiling on available context rather than on response quality – kernel\-managed injection statistically matches performance on two of three models and shows a small, model\-specific deficit on the third, while using substantially shorter prompts: end\-to\-end latency is1515–61%61\\%lower across all three models, with corresponding reductions in per\-call token usage and inference cost\. These results indicate that centralizing memory management in the agent\-system kernel, rather than leaving retrieval and privacy enforcement to individual agents, delivers most of the personalization benefit of unconstrained context at a fraction of its cost\.

![Refer to caption](https://arxiv.org/html/2609.10144v1/teaser.png)Figure 1:Kernel\-managed shared memory centralizes retrieval, privacy enforcement, and prompt injection at the agent\-system kernel instead of leaving them to individual agents \(left vs\. right\), matching full\-context personalization quality at a fraction of the latency and token cost \(Section[4\.4](https://arxiv.org/html/2609.10144#S4.SS4)\)\.## 1Introduction

Personalization is a key ingredient for making AI systems useful: a system that remembers a user’s preferences, current work, and past interactions produces more relevant responses over time\. This is especially true in multi\-agent systems, where different agents learn different parts of a user’s context – one agent may learn stable preferences, another current task context, a third may respond directly to the user – and if that information stays isolated, the system cannot behave coherently as a whole\.

Figure[1](https://arxiv.org/html/2609.10144#S0.F1)contrasts two ways of organizing this\. Under*agent\-managed memory*\(Figure[1](https://arxiv.org/html/2609.10144#S0.F1)a\), each agent independently retrieves, filters, and injects its own memory, duplicating logic across agents and leaving privacy enforcement to per\-agent convention – a design that is easy to get wrong in exactly the way we describe in Section[3\.3](https://arxiv.org/html/2609.10144#S3.SS3)\. We instead propose*kernel\-managed shared memory*\(Figure[1](https://arxiv.org/html/2609.10144#S0.F1)b\): agents write structured, tagged memories, while a runtime layer distinct from any individual agent – the agent\-system kernel – centralizes write ordering, privacy enforcement, retrieval, ranking, and injection\. This makes personalization a systems capability rather than repeated application\-level logic\. We instantiate and evaluate this design on AIOS, an existing operating\-system\-style framework for LLM\-based agents, though the underlying abstraction is not specific to AIOS\.

We evaluate this approach against three alternatives – an unmanaged external memory backend, standard retrieval\-augmented injection, and full unfiltered context concatenation – across three assistant models and 1,800 total trials\. Kernel\-managed shared memory substantially and significantly outperforms the unmanaged memory backend and standard retrieval\-augmented injection on every model tested\. Against full unfiltered context, a soft ceiling on available context rather than on response quality, kernel\-managed injection statistically matches performance on two of three models and shows a small, model\-specific deficit on the third, while using substantially shorter prompts and correspondingly lower latency and token cost\. These results support the paper’s main claim: centralizing memory retrieval, privacy enforcement, and injection in the agent\-system kernel delivers most of the personalization benefit of unconstrained context at a fraction of its cost, and does so more reliably than either an unmanaged memory backend or standard retrieval augmentation\.

## 2Related Work

#### Memory systems for LLM agents\.

Prior work has largely focused on extending persistence beyond the context window: MemoryBank\([Zhong et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib5)\), MemGPT\([Packer et al\., 2023](https://arxiv.org/html/2609.10144#bib.bib2)\), LongMem\([Wang et al\., 2023](https://arxiv.org/html/2609.10144#bib.bib6)\), and ReadAgent\([Lee et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib7)\)each place memory control inside a single agent or model wrapper\. More recent systems improve memory’s structure and adaptability – Mem0\([Chhikara et al\., 2025](https://arxiv.org/html/2609.10144#bib.bib4)\), Zep\([Rasmussen et al\., 2025](https://arxiv.org/html/2609.10144#bib.bib9)\), LangMem\([LangChain Team, 2025](https://arxiv.org/html/2609.10144#bib.bib8)\), and A\-MEM\([Xu et al\., 2025](https://arxiv.org/html/2609.10144#bib.bib3)\)– but memory remains an application\-layer component in all of them; we instead treat access, filtering, formatting, and injection as kernel\-managed operations shared across agents\.

#### Multi\-agent frameworks and shared state\.

Frameworks such as AutoGen\([Wu et al\., 2023](https://arxiv.org/html/2609.10144#bib.bib10)\), CAMEL\([Li et al\., 2023](https://arxiv.org/html/2609.10144#bib.bib11)\), MetaGPT\([Hong et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib12)\), and AgentVerse\([Chen et al\., 2023](https://arxiv.org/html/2609.10144#bib.bib13)\)focus on coordination and role specialization, representing shared state through message passing or workflow\-specific context, with personalization typically reconstructed per agent\. We instead introduce a shared\-memory abstraction letting multiple agents contribute to and consume a unified user context under system\-level policy control\. Recent work treats cross\-agent memory sharing itself as a governance problem: Collaborative Memory\([Rezazadeh et al\., 2025](https://arxiv.org/html/2609.10144#bib.bib23)\)formalizes access control via provenance\-tagged bipartite graphs, SSGM\([Lam et al\., 2026](https://arxiv.org/html/2609.10144#bib.bib24)\)proposes write\-validation and read\-filtering gates against drift, and[Yang et al\. \(2026\)](https://arxiv.org/html/2609.10144#bib.bib25)show that cross\-user leakage can arise from benign interactions alone\. Our visibility rule and write\-ordering barrier \(Sections[3\.3](https://arxiv.org/html/2609.10144#S3.SS3),[3\.4](https://arxiv.org/html/2609.10144#S3.SS4)\) target the same failure class through a simpler mechanism – static per\-item metadata and a single sequence\-numbered barrier rather than bipartite permission graphs or drift\-modeling gates\.

#### Personalization and user modeling\.

Personalization in LLMs is commonly framed as retrieval, prompting, fine\-tuning, or user modeling\([Lewis et al\., 2020](https://arxiv.org/html/2609.10144#bib.bib14);[Salemi et al\., 2024b](https://arxiv.org/html/2609.10144#bib.bib15);[Salemi et al\., 2024a](https://arxiv.org/html/2609.10144#bib.bib26);[Kumar et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib16);[Zhang et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib17);[Liu et al\., 2025](https://arxiv.org/html/2609.10144#bib.bib27);[Tan and Jiang, 2023](https://arxiv.org/html/2609.10144#bib.bib18)\), assuming a single application or inference path; none addresses how a multi\-agent system decides which facts are visible to which agent, when to retrieve them, or how to inject them – questions we treat as kernel\-level infrastructure\.

#### OS\-inspired agent infrastructure\.

AIOS\([Mei et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib1)\)separates agent applications from kernel\-managed services such as scheduling and memory management; OS\-Copilot\([Wu et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib19)\), SWE\-agent\([Yang et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib20)\), and OpenHands\([Wang et al\., 2024](https://arxiv.org/html/2609.10144#bib.bib21)\)similarly emphasize runtime infrastructure over prompting alone, and MemOS\([Li et al\., 2025](https://arxiv.org/html/2609.10144#bib.bib22)\)argues memory should be schedulable\. We build on this perspective but focus on a narrower gap: existing infrastructure does not make shared personalization memory the central kernel service through which agents obtain user\-specific state\.

## 3Methodology and Architecture

### 3\.1Overview and System Model

We propose kernel\-managed shared memory as a system\-level abstraction for personalization in multi\-agent LLM systems\. The central design choice is to move personalization logic out of individual agents and into the agent\-system kernel: agents write structured memories with standardized metadata, while the kernel manages identity resolution, write ordering, retrieval, privacy filtering, ranking, formatting, token\-budget control, and prompt injection\. Although our implementation is built on AIOS, the abstraction is not specific to AIOS: any multi\-agent runtime with a shared memory backend and a controlled prompt\-construction path can implement the same design\. We refer to the system layer generically as the*agent\-system kernel*, with AIOS as our concrete instantiation\.

We consider a multi\-agent system with agents𝒜=\{a1,a2,…,an\}\\mathcal\{A\}=\\\{a\_\{1\},a\_\{2\},\\ldots,a\_\{n\}\\\}and a memory storeℳ\\mathcal\{M\}\. Each agent receives a queryq=\(ai,u,x\)q=\(a\_\{i\},u,x\), whereaia\_\{i\}is the requesting agent,uuis the user identifier, andxxis the input prompt\. A memory item ism=\(u,o,t,s,c\)m=\(u,o,t,s,c\), whereoois the owner agent,ttis the memory type,ssis the sharing policy, andccis the content\. Memory types includeprofile,task\_context, andconversation; sharing policies areprivateorshared\.

#### Resolving user identity\.

Agents do not share a consistent notion of user identity independent of the kernel, and naively using the requesting agent’s own identifier as a proxy produces cross\-user contamination under concurrent trials\. We instead resolveuuthrough an explicit priority order – an identifier attached to the request, the most recently registered session identifier, a fallback registry of previously observed identifiers, and the requesting agent’s own identifier as a last resort – enforced uniformly at the kernel boundary rather than left to per\-agent convention, closing a class of identity\-resolution bugs encountered during development \(Section[4](https://arxiv.org/html/2609.10144#S4)\)\.

The kernel transforms the original prompt into an augmented promptx′=K⁡\(ai,u,x\)x^\{\\prime\}=K\(a\_\{i\},u,x\), whereKKdenotes the kernel\-managed personalization function\.

### 3\.2Kernel\-Managed Shared Memory

![Refer to caption](https://arxiv.org/html/2609.10144v1/system_wide_personalization_architecture.png)Figure 2:Kernel\-managed shared memory: ProfileAgent and TaskAgent write structured memories, AssistantAgent remains retrieval\-free, and the kernel enforces write ordering, privacy, retrieval, formatting, and injection between them\.Figure[2](https://arxiv.org/html/2609.10144#S3.F2)shows the proposed architecture\. ProfileAgent and TaskAgent act as memory\-producing agents, extracting stable user information and current task context, respectively\. AssistantAgent acts as a retrieval\-free consumer: it does not query the memory backend directly and does not construct its own personalization prompt; all personalization context reaches it through the kernel\-managed prompt path\.

The kernel implements personalization through five operations: \(1\) enforce write\-before\-read ordering for the target user \(Section[3\.4](https://arxiv.org/html/2609.10144#S3.SS4)\); \(2\) retrieve candidate memories,R=search⁡\(ℳ,u,x\)R=\\mathrm\{search\}\(\\mathcal\{M\},u,x\); \(3\) filter retrieved memories according to the system visibility rule \(Section[3\.3](https://arxiv.org/html/2609.10144#S3.SS3)\); \(4\) rank and truncate the filtered memories by semantic relevance and token budget; and \(5\) inject the selected memories,x′=inject⁡\(x,Rk\)x^\{\\prime\}=\\mathrm\{inject\}\(x,R\_\{k\}\)– part of the system call path rather than application\-specific prompt construction, unlike agent\-level memory systems\.

### 3\.3Memory Metadata and Visibility

Each memory item carries standardized metadata:owner\_agent,user\_id,memory\_type, andsharing\_policy\. The important design choice is thatowner\_agentanduser\_idare independent: multiple agents may write memories about the same user, but ownership and visibility remain explicit\. The kernel enforces memory visibility through the following rule:

visible⁡\(m,ai\)=\{Trueif​o=ai,Trueif​s=“shared”,Falseotherwise\.\\mathrm\{visible\}\(m,a\_\{i\}\)=\\begin\{cases\}\\mathrm\{True\}&\\text\{if \}o=a\_\{i\},\\\\ \\mathrm\{True\}&\\text\{if \}s=\\text\{\`\`shared''\},\\\\ \\mathrm\{False\}&\\text\{otherwise\.\}\\end\{cases\}\(1\)If the sharing policy is absent, malformed, or explicitly private, the memory is treated as private, making privacy a kernel invariant rather than an SDK convention or prompt\-level instruction\.

#### Privacy invariant\.

Unlike the write\-ordering guarantee of Section[3\.4](https://arxiv.org/html/2609.10144#S3.SS4), which bounds a*temporal*property, the visibility rule is a*static*property of memory metadata alone\. Formally, for all memoriesmmand agentsai≠aja\_\{i\}\\neq a\_\{j\}witho⁡\(m\)=ajo\(m\)=a\_\{j\}ands⁡\(m\)=privates\(m\)=\\text\{private\},

visible⁡\(m,ai\)=Falsefor every execution history\.\\mathrm\{visible\}\(m,a\_\{i\}\)=\\mathrm\{False\}\\quad\\text\{for every execution history\}\.\(2\)This is a safety property that holds unconditionally, unlike Eq\.[3](https://arxiv.org/html/2609.10144#S3.E3), which is a liveness/consistency property holding only up to a bounded timeout\.

#### Threat model and empirical verification\.

Enforcing visibility once, at the kernel, means an agent cannot exfiltrate memories merely by omitting its own filtering logic, though this guarantee covers visibility \(not integrity\) and is conditional on correct identity resolution \(full threat model in Appendix[A\.2](https://arxiv.org/html/2609.10144#A1.SS2)\)\. We verify Eq\.[2](https://arxiv.org/html/2609.10144#S3.E2)empirically at both configuration endpoints: fully private \(n=450n=450\) shows0/4500/450exposure, and fully shared \(n=450n=450\) shows no leakage of the private\-by\-defaultconversationtype among1,7981\{,\}798retrieved items\.

### 3\.4Cross\-Agent Retrieval Pipeline and Write\-Ordering Guarantee

Given a user query, the kernel resolves the targetuser\_id\(Section[3\.1](https://arxiv.org/html/2609.10144#S3.SS1)\), waits for any pending writes for that user to be durably confirmed \(below\), retrieves candidate memories, filters them by ownership and sharing policy, merges and deduplicates results, ranks by semantic relevance, formats into natural language, truncates to the token budget, and prepends the resulting memory block to the assistant prompt\. This exposes a unified user context to multiple agents while preventing direct access to private agent\-local memories, so cross\-agent personalization is achieved without requiring AssistantAgent to implement retrieval, filtering, or prompt construction itself\.

Because ProfileAgent and TaskAgent write memories asynchronously relative to AssistantAgent’s retrieval, a naive implementation is subject to a race condition: retrieval may execute before writer agents’ memories are durably indexed, silently degrading personalization with no observable error\. We address this with a per\-user\_idwrite barrier: each write is stamped with a monotonically increasing sequence number at acceptance time, scoped to the targetuser\_id; each retrieval snapshots the highest sequence number issued for that user and blocks until all writes up to that snapshot are confirmed drained, subject to a bounded timeout \(default 5000 ms\), after which it proceeds in a fail\-open mode that prioritizes liveness over strict consistency \(design rationale in Appendix[A\.7](https://arxiv.org/html/2609.10144#A1.SS7)\)\.

Formally, letσ⁡\(w\)\\sigma\(w\)denote the sequence number assigned to writewwfor useruu, and letσ∗​\(u\)\\sigma^\{\*\}\(u\)denote the highest sequence number issued foruuat the time a retrievalrrbegins\. The barrier guarantees:

robserves\{w:o\(w\)=u,σ\(w\)≤σ∗\(u\)\}or timeout\(u\)elapses\.r\\text\{ observes \}\\\{w:o\(w\)=u,\\ \\sigma\(w\)\\leq\\sigma^\{\*\}\(u\)\\\}\\quad\\text\{or timeout\}\(u\)\\text\{ elapses\}\.\(3\)This gives read\-after\-write consistency scoped to a single user, without global locking or blocking retrievals for unrelated users\. It eliminates a class of nondeterministic injection failures, but does not by itself guarantee correct scoping or formatting; we report its empirical contribution, independent of those fixes, in Appendix[A\.5](https://arxiv.org/html/2609.10144#A1.SS5)\.

### 3\.5Memory Representation, Formatting, and Agent Roles

Structured storage does not imply structured injection: in early experiments, raw JSON memory content was difficult for smaller local models to use reliably\. The kernel therefore applies a formatting functioncm′=format⁡\(cm\)c^\{\\prime\}\_\{m\}=\\mathrm\{format\}\(c\_\{m\}\), rendering profile and task memories as natural\-language statements in place of raw JSON, while the structured form is preserved for retrieval and auditing \(isolated as an independent ablation, Appendix[A\.5](https://arxiv.org/html/2609.10144#A1.SS5)\)\.

We instantiate the method with three agents: ProfileAgent extracts stable user attributes \(preferences, tools, language, response style\); TaskAgent extracts short\-term working context \(goals, blockers, next steps\); and AssistantAgent generates user\-facing responses from kernel\-injected context, performing no retrieval of its own\. The method is implemented as a kernel abstraction over LLM and memory operations, supporting configurable extraction, injection, relevance thresholds, memory budgets, write\-barrier timeout, and pluggable memory providers, all inference\-time only with no retraining required\.

## 4Experiments

### 4\.1Baselines

A central question is whether observed gains come from the kernel’s specific architectural choices – write ordering, identity resolution, centralized privacy enforcement, cross\-agent visibility – or simply from providing*any*additional context\. We compare against three external baselines plus the proposed method \(Table[1](https://arxiv.org/html/2609.10144#S4.T1)\)\.naive\_concatandvanilla\_raginvolve no memory system\-level orchestration at all, andmem0\_defaultinvolves an external memory system without kernel management, so any advantage ofkernel\_sharedcannot be attributed merely to the presence of injected context; comparing againstmem0\_defaultspecifically isolates kernel\-level write ordering, identity resolution, and privacy enforcement, since both conditions use the same underlying provider\.

Table 1:Baselines compared against the proposed method\.
### 4\.2Models, Trials, Evaluation, and Configuration

We evaluate all four methods across three assistant models of varying capability – GPT\-4o, Llama\-3\.1:8B, and Qwen\-2\.5:7B – to distinguish architectural effects from effects better explained by capability alone\. Each trial generates a synthetic user profile, a synthetic task context, and a vague follow\-up query \(e\.g\., “What should I focus on next?”\), intentionally underspecified so personalized content must come from injected memory rather than the query itself\.

Each trial is scored by GPT\-5\.4 along three dimensions on a 1–5 scale:Profile Usage,Task Usage, andIntegration\(whether profile and task information are combined coherently\)\. We use GPT\-5\.4, a model distinct from every assistant evaluated, as the sole judge across all twelve \(model, method\) conditions to avoid a self\-preference effect in LLM\-as\-judge evaluation\.

The kernel ran withauto\_extract: true,auto\_inject: true, a relevance threshold of0\.30\.3, a maximum of1010injected memories per call, a memory token budget of20002000, and the write barrier \(Section[3\.4](https://arxiv.org/html/2609.10144#S3.SS4)\) enabled with a50005000ms timeout\. Each of the twelve conditions was run for150150trials \(1,8001\{,\}800total\)\.

### 4\.3Human Validation

To validate the automated judge, we constructed a blinded human\-rated subset \(30 GPT\-4o trials, 24 unique items plus 6 duplicates for intra\-rater consistency; design in Appendix[A\.1](https://arxiv.org/html/2609.10144#A1.SS1)\)\. Human and automated judge scores matched exactly on41\.7%41\.7\\%of items and agreed within one point on83\.3%83\.3\\%\(mean absolute error0\.750\.75\), and were strongly correlated \(Spearman’sρ=0\.727\\rho=0\.727,p=5\.7×10−5p=5\.7\\times 10^\{\-5\}\)\. The human rater confirms our central GPT\-4o comparison:kernel\_sharedandnaive\_concatare indistinguishable in human\-perceived quality \(4\.174\.17vs\.4\.174\.17\), both far abovemem0\_default\(1\.001\.00\) – an independent confirmation not filtered through the automated judge\. The judge does under\-creditvanilla\_ragrelative to the human rater \(2\.172\.17vs\.3\.673\.67\), consistent with the architectural failure mode in Section[4\.4](https://arxiv.org/html/2609.10144#S4.SS4)wherevanilla\_ragsystematically drops profile content; per\-method agreement and intra\-rater consistency detail are in Appendix[A\.1](https://arxiv.org/html/2609.10144#A1.SS1)\.

### 4\.4Quantitative Results

Table[2](https://arxiv.org/html/2609.10144#S4.T2)reports mean scores with standard deviations across all twelve \(model, method\) conditions, 150 trials each\.

Table 2:Full results across 3 models×\\times4 methods, 150 trials per condition, judged by GPT\-5\.4\. Values are mean±\\pmSD\.Three patterns hold across all three models\. First,vanilla\_ragprofile scores stay flat regardless of model capability \(1\.841\.84/1\.911\.91/1\.841\.84\) while task scores are both higher and similarly flat \(3\.843\.84/3\.783\.78/3\.843\.84\) – an architectural failure, not a capability one: the follow\-up query is closer to task content, so retrieval consistently drops profile chunks regardless of the model’s capacity to use them if present\. Second,mem0\_defaultscores near floor throughout; since it shareskernel\_shared’s underlying provider, this isolates write\-ordering and identity\-resolution guarantees, not the mere presence of a memory backend, as the source of the gap\. Third,kernel\_sharedvs\.naive\_concatis model\-dependent \(Welch’stt, Mann–WhitneyUU, bootstrap CI; full nine model×\\timesdimension comparisons and figure in Appendix[A\.3](https://arxiv.org/html/2609.10144#A1.SS3)\): it tiesnaive\_concaton GPT\-4o Profile/Integration and all three Qwen\-2\.5:7B dimensions, is higher on GPT\-4o Task \(p=0\.006p=0\.006\), and is significantly*lower*on Llama\-3\.1:8B Task/Integration \(rank\-biserial0\.130\.13–0\.190\.19, unexplained by scale\)\. Againstvanilla\_ragandmem0\_default, by contrast, the advantage is large and overwhelmingly significant everywhere \(allp<10−18p<10^\{\-18\}, rank\-biserial0\.440\.44–1\.001\.00\): kernel\-managed injection’s downside is capped at a small, model\-specific gap against unfiltered context, while its advantage over an unmanaged backend or plain retrieval is categorical\.

### 4\.5Latency Analysis

kernel\_sharedachieves substantially lower end\-to\-end latency thannaive\_concaton all three models:7\.57\.5s vs\.19\.219\.2s on GPT\-4o,21\.721\.7s vs\.25\.525\.5s on Llama\-3\.1:8B, and26\.326\.3s vs\.36\.336\.3s on Qwen\-2\.5:7B \(1515–61%61\\%reduction\)\. The mechanism differs by model \(full analysis in Appendix[A\.4](https://arxiv.org/html/2609.10144#A1.SS4)\): on Llama\-3\.1:8B, output length does not differ significantly between conditions \(p=0\.27p=0\.27\) yetkernel\_sharedis still15%15\\%faster, pointing to input\-side savings; on GPT\-4o and Qwen\-2\.5:7B,naive\_concatproduces significantly longer outputs \(\+159\+159and\+83\+83words,p<0\.0001p<0\.0001\), accounting for part of the gap\.mem0\_default’s low latency simply reflects little content to inject\. This latency win holds regardless of outcome on thenaive\_concatquality comparison above\.

## 5Discussion and Conclusion

Kernel\-managed shared memory reliably outperforms a standard RAG pipeline and an unmanaged external memory backend across all three models, at lower latency than full unfiltered context; thenaive\_concatcomparison is more nuanced, tying on two of three models with a Llama\-3\.1:8B deficit unexplained by scale, left to future work\.

## Acknowledgments and Disclosure of Funding

We thank the AIOS project contributors and collaborators whose prior architecture and tooling made this extension possible\.

## References

- W\. Chen, Y\. Su, J\. Zuo, C\. Yang, C\. Yuan, C\. Chan, H\. Yu, Y\. Lu, Y\. Hung, C\. Qian, Y\. Qin, X\. Cong, R\. Xie, Z\. Liu, M\. Sun, and J\. ZhouAgentVerse: facilitating multi\-agent collaboration and exploring emergent behaviors\.arXiv preprint arXiv:2308\.10848\.External Links:[Link](https://arxiv.org/abs/2308.10848)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- Chhikaraet al\.\(2025\)P\. Chhikara, D\. Khant, S\. Aryan, T\. Singh, and D\. YadavMem0: building production\-ready ai agents with scalable long\-term memory\.arXiv preprint arXiv:2504\.19413\.External Links:[Link](https://arxiv.org/abs/2504.19413)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Honget al\.\(2024\)S\. Hong, M\. Zhuge, J\. Chen, X\. Zheng, Y\. Cheng, J\. Wang, C\. Zhang, Z\. Wang, S\. K\. S\. Yau, Z\. Lin,et al\.MetaGPT: meta programming for a multi\-agent collaborative framework\.InInternational Conference on Learning Representations,External Links:[Link](https://arxiv.org/abs/2308.00352)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- Kumaret al\.\(2024\)I\. Kumar, S\. Viswanathan, S\. Yerra, A\. Salemi, R\. A\. Rossi, F\. Dernoncourt, H\. Deilamsalehy, X\. Chen, R\. Zhang, S\. Agarwal,et al\.LongLaMP: a benchmark for personalized long\-form text generation\.arXiv preprint arXiv:2407\.11016\.External Links:[Link](https://arxiv.org/abs/2407.11016)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Lamet al\.\(2026\)C\. Lam, J\. Li, L\. Zhang, and K\. ZhaoGoverning evolving memory in LLM agents: risks, mechanisms, and the stability and safety governed memory \(SSGM\) framework\.arXiv preprint arXiv:2603\.11768\.Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- LangChain Team \(2025\)LangChain TeamLangMem: long\-term memory for agents\.Note:[https://langchain\-ai\.github\.io/langmem/](https://langchain-ai.github.io/langmem/)Accessed 2026\-04\-25Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Leeet al\.\(2024\)K\. Lee, X\. Chen, H\. Furuta, J\. Canny, and I\. FischerA human\-inspired reading agent with gist memory of very long contexts\.arXiv preprint arXiv:2402\.09727\.External Links:[Link](https://arxiv.org/abs/2402.09727)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Lewiset al\.\(2020\)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\. KielaRetrieval\-augmented generation for knowledge\-intensive nlp tasks\.InAdvances in Neural Information Processing Systems,Vol\.33,pp\. 9459–9474\.Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Liet al\.\(2023\)G\. Li, H\. A\. A\. K\. Hammoud, H\. Itani, D\. Khizbullin, and B\. GhanemCAMEL: communicative agents for “mind” exploration of large language model society\.InAdvances in Neural Information Processing Systems,External Links:[Link](https://arxiv.org/abs/2303.17760)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- Liet al\.\(2025\)Z\. Li, C\. Xi, C\. Li, D\. Chen, B\. Chen, S\. Song, S\. Niu, H\. Wang, J\. Yang, C\. Tang, Q\. Yu, J\. Zhao, Y\. Wang, P\. Liu, Z\. Lin, P\. Wang, J\. Huo, T\. Chen, K\. Chen, K\. Li, Z\. Tao, H\. Lai, H\. Wu, B\. Tang, Z\. Wang, Z\. Fan, N\. Zhang, L\. Zhang, J\. Yan, M\. Yang, T\. Xu, W\. Xu, H\. Chen, H\. Wang, H\. Yang, W\. Zhang, Z\. J\. Xu, S\. Chen, and F\. XiongMemOS: a memory os for ai system\.External Links:2507\.03724Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px4.p1.1)\.
- Liuet al\.\(2025\)J\. Liu, Z\. Qiu, Z\. Li, Q\. Dai, W\. Yu, J\. Zhu, M\. Hu, M\. Yang, T\. Chua, and I\. KingA survey of personalized large language models: progress and future directions\.External Links:2502\.11528,[Link](https://arxiv.org/abs/2502.11528)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Meiet al\.\(2024\)K\. Mei, X\. Zhu, W\. Xu, M\. Jin, W\. Hua, Z\. Li, S\. Xu, R\. Ye, Y\. Ge, and Y\. ZhangAIOS: llm agent operating system\.arXiv preprint arXiv:2403\.16971\.External Links:[Link](https://arxiv.org/abs/2403.16971)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px4.p1.1)\.
- Packeret al\.\(2023\)C\. Packer, S\. Wooders, K\. Lin, V\. Fang, S\. G\. Patil, I\. Stoica, and J\. E\. GonzalezMemGPT: towards llms as operating systems\.arXiv preprint arXiv:2310\.08560\.External Links:[Link](https://arxiv.org/abs/2310.08560)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Rasmussenet al\.\(2025\)P\. Rasmussen, P\. Paliychuk, T\. Beauvais, J\. Ryan, and D\. ChalefZep: a temporal knowledge graph architecture for agent memory\.arXiv preprint arXiv:2501\.13956\.External Links:[Link](https://arxiv.org/abs/2501.13956)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Rezazadehet al\.\(2025\)A\. Rezazadeh, Z\. Li, A\. Lou, Y\. Zhao, W\. Wei, and Y\. BaoCollaborative memory: multi\-user memory sharing in llm agents with dynamic access control\.arXiv preprint arXiv:2505\.18279\.Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- Salemiet al\.\(2024a\)A\. Salemi, S\. Kallumadi, and H\. ZamaniOptimization methods for personalizing large language models through retrieval augmentation\.External Links:2404\.05970,[Link](https://arxiv.org/abs/2404.05970)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Salemiet al\.\(2024b\)A\. Salemi, S\. Mysore, M\. Bendersky, and H\. ZamaniLaMP: when large language models meet personalization\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics,External Links:[Link](https://arxiv.org/abs/2304.11406)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Tan and Jiang \(2023\)Z\. Tan and M\. JiangUser modeling in the era of large language models: current research and future directions\.External Links:2312\.11518,[Link](https://arxiv.org/abs/2312.11518)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Wanget al\.\(2023\)W\. Wang, L\. Dong, H\. Cheng, X\. Liu, X\. Yan, J\. Gao, and F\. WeiAugmenting language models with long\-term memory\.arXiv preprint arXiv:2306\.07174\.External Links:[Link](https://arxiv.org/abs/2306.07174)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Wanget al\.\(2024\)X\. Wang, B\. Li, Y\. Song, F\. F\. Xu, X\. Tang, M\. Zhuge, J\. Pan, Y\. Song, B\. Li, J\. Singh,et al\.OpenHands: an open platform for ai software developers as generalist agents\.arXiv preprint arXiv:2407\.16741\.External Links:[Link](https://arxiv.org/abs/2407.16741)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px4.p1.1)\.
- Wuet al\.\(2023\)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\. WangAutoGen: enabling next\-gen llm applications via multi\-agent conversation framework\.arXiv preprint arXiv:2308\.08155\.External Links:[Link](https://arxiv.org/abs/2308.08155)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- Wuet al\.\(2024\)Z\. Wu, C\. Han, Z\. Ding, Z\. Weng, Z\. Liu, S\. Yao, T\. Yu, and L\. KongOS\-copilot: towards generalist computer agents with self\-improvement\.arXiv preprint arXiv:2402\.07456\.External Links:[Link](https://arxiv.org/abs/2402.07456)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px4.p1.1)\.
- Xuet al\.\(2025\)W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. ZhangA\-mem: agentic memory for llm agents\.arXiv preprint arXiv:2502\.12110\.External Links:[Link](https://arxiv.org/abs/2502.12110)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.
- Yanget al\.\(2024\)J\. Yang, C\. E\. Jimenez, A\. Wettig, K\. Lieret, S\. Yao, K\. Narasimhan, and O\. PressSWE\-agent: agent\-computer interfaces enable automated software engineering\.InAdvances in Neural Information Processing Systems,External Links:[Link](https://arxiv.org/abs/2405.15793)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px4.p1.1)\.
- Yanget al\.\(2026\)T\. Yang, J\. Li, Y\. Nian, S\. Dong, R\. Xu, R\. Rossi, K\. Ding, and Y\. ZhaoNo attacker needed: unintentional cross\-user contamination in shared\-state llm agents\.External Links:2604\.01350,[Link](https://arxiv.org/abs/2604.01350)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px2.p1.1)\.
- Zhanget al\.\(2024\)Z\. Zhang, R\. A\. Rossi, B\. Kveton, Y\. Shao, D\. Yang, H\. Zamani, F\. Dernoncourt, J\. Barrow, T\. Yu, S\. Kim,et al\.Personalization of large language models: a survey\.arXiv preprint arXiv:2411\.00027\.External Links:[Link](https://arxiv.org/abs/2411.00027)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px3.p1.1)\.
- Zhonget al\.\(2024\)W\. Zhong, L\. Guo, Q\. Gao, H\. Ye, and Y\. WangMemoryBank: enhancing large language models with long\-term memory\.InProceedings of the AAAI Conference on Artificial Intelligence,Vol\.38,pp\. 19724–19731\.External Links:[Document](https://dx.doi.org/10.1609/aaai.v38i17.29946)Cited by:[§2](https://arxiv.org/html/2609.10144#S2.SS0.SSS0.Px1.p1.1)\.

## Appendix ATechnical Appendix

### A\.1Human Validation Design Detail

We sampled 30 GPT\-4o trials: 6 unique items per method across all four methods \(24 unique items\), plus 6 duplicate items inserted at separated positions to measure intra\-rater consistency\. Items were presented in randomized order under opaque identifiers, with the rater blind to both condition and automated judge score\. A single rater scored each item on the Integration dimension using the same 1–5 rubric given to the automated judge\.

Table 3:Human rater vs\. automated judge agreement, by method \(GPT\-4o, Integration dimension,N=6N=6per method\)\.Intra\-rater consistency on the 6 duplicate pairs was high: the rater gave the exact same score on 5 of 6 repeats, with a mean absolute difference of0\.170\.17across all six pairs\. We note the use of a single rater precludes computing inter\-rater reliability statistics such as Krippendorff’sα\\alpha\. Read together, the judge appears to be a trustworthy proxy for the paper’s central claim, since its one documented miscalibration under\-credits a baseline rather than over\-crediting the proposed method\.

### A\.2Threat Model and Empirical Verification Detail

#### Threat model\.

We consider an adversary model in which one agent – compromised, buggy, or simply malicious – attempts to read memories it is not authorized to see: either another agent’s private memories for the same user, or any agent’s memories for a different user entirely\. Because visibility is checked once, at the kernel, on every retrieval path \(Eq\.[2](https://arxiv.org/html/2609.10144#S3.E2)\), such an agent cannot exfiltrate private memories simply by skipping its own filtering logic; it would need to compromise the kernel’s enforcement point directly, a materially higher bar than omitting a check in one ofnnindependently\-trusted implementations\. This protection has two concrete limits\. First, the kernel enforces*visibility*, not*integrity*or*provenance*: a malicious ProfileAgent can still corrupt what AssistantAgent believes about a user\. Second, the kernel enforces visibility*given a resolved user identity*; it does not independently verify that the identity presented to it is correct\. If the identity\-resolution fallback chain \(Section[3\.1](https://arxiv.org/html/2609.10144#S3.SS1)\) can be induced to resolve to the wronguser\_id– for instance, by an agent that races to register itself as the most recent session for a target user before the legitimate session does – the visibility rule would faithfully enforce access control for the*wrong*partition, a failure of identity resolution rather than of visibility enforcement, but with the same practical consequence\. We have not evaluated the identity\-resolution fallback chain against an adversarial agent attempting this\.

#### Empirical verification at both configuration endpoints\.

We have not run a designed sweep over intermediate sharing configurations or an adversarial query campaign; both are future work\. Our existing benchmark trials \(Section[4](https://arxiv.org/html/2609.10144#S4)\) provide a zero\-cost empirical check of Eq\.[2](https://arxiv.org/html/2609.10144#S3.E2)at the two endpoints of the sharing policy\. At the fully\-private endpoint \(mem0\_default,n=450n=450trials across three models, all memories writtenprivate\), retrieval\-eligible cross\-agent exposure is0/4500/450\. Functional exposure is0/4500/450as well, with one apparent exception we verified by hand: a single trial scored3/53/5on Task Usage despite zero memories retrieved, which we trace to the automated judge crediting generic clarifying language rather than any genuinely leaked content – a judge\-calibration artifact, not a privacy failure\. At the fully\-shared endpoint \(kernel\_shared,n=450n=450trials\), we additionally checked whether sharing one memory type inadvertently widens exposure of another: of1,7981\{,\}798total memory items retrieved across all trials, none were the private\-by\-defaultconversationtype written by theConversationExtractor\(Appendix[A\.6](https://arxiv.org/html/2609.10144#A1.SS6)\), confirming thatsharing\_policyscoping is enforced per memory item rather than per writer agent\.

### A\.3Significance Testing Detail

Table[4](https://arxiv.org/html/2609.10144#A1.T4)and Figure[3](https://arxiv.org/html/2609.10144#A1.F3)report the full nine \(model, dimension\)kernel\_sharedvs\.naive\_concatcomparisons underlying the discussion in Section[4\.4](https://arxiv.org/html/2609.10144#S4.SS4)\.

Figure 3:Mean difference and 95% bootstrap CI for the ninekernel\_sharedvs\.naive\_concatcomparisons; six of nine intervals cross zero \(dashed line\), indicating no significant difference\.Table 4:kernel\_sharedvs\.naive\_concat: mean difference and significance across all three models \(independent samples,n=150n=150per condition\)\. Bold marksp<0\.05p<0\.05under both Welch’stt\-test and Mann–WhitneyUU\.
### A\.4Latency Mechanism Detail

Table[5](https://arxiv.org/html/2609.10144#A1.T5)reports output length \(word count\) by condition and model, alongside a Welch’stt\-test on thekernel\_sharedvs\.naive\_concatdifference and the within\-condition correlation between output length and latency\.

Table 5:Output length \(words\) by condition and model, with significance of thekernel\_sharedvs\.naive\_concatdifference and the within\-condition correlation between output length and latency\.rr\(words, latency\) reported askernel\_shared/naive\_concat, bothp<10−11p<10^\{\-11\}\.

Within every condition, word count and latency are strongly correlated \(r=0\.52r=0\.52–0\.860\.86, allp<10−11p<10^\{\-11\}\), confirming generation length is a major latency driver in general; the relevant question is whether that driver differs*systematically between conditions*, which it does for GPT\-4o and Qwen\-2\.5:7B but not for Llama\-3\.1:8B \(no significant difference,p=0\.27p=0\.27, yetkernel\_sharedremains15%15\\%faster – implicating input\-side savings rather than generation length for that model\)\.mem0\_default’s short, generic outputs follow the same pattern of low content, low latency, and are excluded from the table since they are not a meaningful comparison point\. One plausible reading of the GPT\-4o and Qwen\-2\.5:7B asymmetry is that unfiltered, unstructured context prompts the model toward longer, more exhaustive responses, while curated, kernel\-formatted context elicits a more targeted one; we did not design an experiment specifically to test this explanation and note it as a plausible mechanism rather than a demonstrated one, for future work\.

### A\.5Ablation Pilot Detail

Table[6](https://arxiv.org/html/2609.10144#A1.T6)reports the full pilot ablation deltas underlying the pilot ablation study conducted during development\. Raw JSON injection, evaluated with an LLM\-only judge, scored worse than the private baseline on all three dimensions \(row 1\); natural\-language formatting and an explicit system\-prompt instruction each narrowed this gap without closing it \(rows 2–3\); only adopting the hybrid keyword\+LLM judge produced a positive result \(row 4\)\. This pilot \(Qwen\-2\.5:7B, 30 trials\) predates the verification pass applied to our main results and carries no evidentiary weight toward the paper’s central claims – it is included for its qualitative documentation of the design trajectory only\.

Table 6:Ablation: Phase 2 \(shared\)−\-Phase 1 \(private\) score deltas across successive pipeline and evaluation refinements \(Qwen\-2\.5:7B, 30\-trial pilot\)\.
### A\.6System Call Interface

Table[7](https://arxiv.org/html/2609.10144#A1.T7)lists the kernel modules involved in personalization and their corresponding operations, in the style of the system\-call catalog used by prior OS\-inspired agent infrastructure \(e\.g\., AIOS’s kernel syscall table\)\.

Table 7:Kernel modules and their corresponding operations for shared\-memory personalization\.Each agent\-facing call \(e\.g\.,create\_memory,llm\_chat\) is routed through the SDK to one or more of these module\-level operations; agents never callMem0ProviderorMemoryWriteBarrierdirectly\. This indirection is what allows the kernel to change providers, retrieval strategies, or barrier timeouts without requiring changes to agent code\.

### A\.7Write Barrier Implementation

The write barrier described in Section[3\.4](https://arxiv.org/html/2609.10144#S3.SS4)is implemented as a per\-user\_idsequence counter with acquire and release operations, sketched below:

> class MemoryWriteBarrier: def acquire\(self, user\_id\): \# assigns and returns the next sequence number for user\_id \.\.\. def release\(self, user\_id, seq\_no, success\): \# marks seq\_no as drained \(committed or failed\) for user\_id; \# notifies any retrieval waiting on this or an earlier seq\_no \.\.\. def snapshot\(self, user\_id\): \# returns the current high\-water mark σ∗\\sigma^\{\*\}\(user\_id\) \.\.\.def wait\_until\_drained\(self, user\_id, snapshot, timeout\_ms=5000\): \# blocks until all writes with seq\_no <= snapshot are released, \# or returns early \(fail\-open\) after timeout\_ms elapses \.\.\.

We choose a bounded wait with fail\-open behavior over strict locking because a stalled write degrades personalization rather than violating correctness – the assistant can still respond with partial context – mirroring the fail\-open/fail\-closed asymmetry in Section[3\.3](https://arxiv.org/html/2609.10144#S3.SS3)\(liveness degrades gracefully; visibility never fails open\)\. A failed write still callsrelease\(withsuccess=False\), so a provider error never strands a waiting retrieval past the bounded timeout\. This cost is scoped to a singleuser\_idand bounded by the number of writer agents rather than memory\-store size; we have not evaluated behavior at larger memory\-store sizes\.

### A\.8Kernel\-Managed Memory Injection

The injection pipeline performs the following steps: extract the latest user query; retrieve candidate memories using semantic search; derive the targetuser\_idfrom retrieved metadata; perform cross\-agent retrieval for shared memories; merge and deduplicate results; filter by relevance score; sort by relevance; format structured memory into natural language; truncate to a token budget; and inject as a system message prepended with===== MEMORY CONTEXT =====\. This design ensures personalization is applied uniformly without requiring agents to explicitly request memory\.

### A\.9Cross\-Agent Memory Resolution

The kernel resolves shared memory using a two\-stage retrieval process: retrieve agent\-scoped memories, inferuser\_id, then retrieve shared memories from other agents\. If no user ID is found locally, the kernel falls back to a global registry of known users, enabling cross\-agent personalization even when the requesting agent has no prior memory – zero\-shot personalization across agents and memory reuse without explicit coordination\.

### A\.10Evaluation Pipeline and Hybrid Metric

The evaluation pipeline runs ProfileAgent, then TaskAgent, then AssistantAgent under two conditions: Phase 1 \(private memory only\) and Phase 2 \(shared memory enabled\), differing only in sharing policy\. The early hybrid scoring mechanism combined deterministic keyword matching with LLM\-based evaluation across Profile, Task, and Integration:

score=keyword score\+LLM score2,\\text\{score\}=\\frac\{\\text\{keyword score\}\+\\text\{LLM score\}\}\{2\},\(4\)trading robustness \(keyword matching\) for semantic evaluation \(LLM judge\)\. Each trial in the synthetic evaluation harness logs injected memory count, cross\-agent retrieval, personalization scores, and latency, aggregated into summary statistics including mean, standard deviation, and min/max values\.