Governed Shared Memory for Multi-Agent LLM Systems
This paper introduces MemClaw, a production multi-tenant memory service that implements governed shared memory primitives to address critical failure modes in multi-agent LLM systems, while using the ArgusFleet evaluation harness to reveal real-world architectural challenges like asymmetric scope enforcement and pipeline ordering conflicts that design-only approaches often miss.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a team of AI assistants working together on a massive project, like a digital construction crew building a skyscraper. In the past, each assistant had its own private notebook. If Assistant A wrote down a measurement, Assistant B couldn't see it unless someone physically handed them the notebook.
This paper argues that as AI teams grow, they can't just have private notebooks anymore. They need a shared, governed whiteboard where everyone can write and read, but with strict rules about who can see what, when, and how.
The authors call this system "Governed Shared Memory." They built a real version of it called MemClaw and tested it with a robot tester called ArgusFleet to see if it actually works in the real world.
Here is the breakdown of their findings using simple analogies:
1. The Problem: The "Wild West" of Shared Memory
In the old days, AI memory was just about remembering the conversation (like a chat history). But now, with fleets of agents, memory is like operational state.
- The Analogy: Imagine a hospital. A nurse (Agent A) updates a patient's allergy info. A doctor (Agent B) needs to see that update immediately. If the doctor sees the old info, the patient gets hurt.
- The Challenge: It's not just about finding the info (retrieval); it's about governance. Who is allowed to see it? Is the info old or new? Who wrote it? If two people write conflicting things, which one wins?
2. The Four "Disasters" They Prevented
The authors identified four ways this system could fail, like four different ways a shared office could go wrong:
- Unauthorized Leakage: A janitor (Agent A) accidentally reads the CEO's private salary notes.
- Stale Propagation: The janitor reads the CEO's notes, but the notes are from last year, so the janitor acts on outdated info.
- Contradiction Persistence: Two people write on the whiteboard at the same time. One writes "Meeting at 2 PM," the other writes "Meeting at 3 PM." Both stay on the board, confusing everyone.
- Provenance Collapse: Someone erases a note and writes a new one, but there's no record of who wrote it or when. It's like a mystery: "Who changed the schedule?"
3. The Solution: The "Governed Whiteboard" (MemClaw)
They built MemClaw, a system that acts like a smart, rule-enforcing whiteboard.
- Scoped Retrieval: It's like a security guard at a door. If you don't have the right badge (permission), you can't even see the room, let alone read the notes.
- Temporal Supersession: If someone writes a new note, the old one is automatically crossed out and marked "Obsolete."
- Provenance Tracking: Every note has a digital signature saying exactly who wrote it and when.
- Policy Propagation: It controls how notes move between different groups (fleets) so secrets don't leak.
4. The Test: "ArgusFleet" (The Robot Inspector)
They didn't just guess if it worked; they built ArgusFleet, a robot tester that tried to break the system. It acted like a security auditor trying to sneak into restricted areas or find old, conflicting notes.
What they found (The Good News):
- The "Who Wrote It" Test: They created 50 chains of notes (like a family tree of information). The system perfectly traced every note back to the original writer, even deep in the chain, in less than a second.
- The "Secrets" Test: When they tried to sneak a note from one team to another, the system blocked it 100% of the time. No leaks.
- The "Speed" Test: When a note was written, it became visible to the right people almost instantly (about 0.8 seconds). It wasn't a slow, "eventual" update; it was immediate.
What they found (The Bad News & Fixes):
- The "Back Door" Bug: They found a hole in the security. If you knew the specific ID number of a note, you could grab it directly, even if you weren't supposed to see it. The system checked your ID for the search function but ignored it for the direct grab function.
- The Fix: They patched this hole immediately. Now, even if you have the ID number, the system checks your badge before letting you grab the note.
- The "Confused Gatekeeper" Bug: The system had two security guards. One checked if a note was a "duplicate" (synchronous), and the other checked if it was a "contradiction" (asynchronous). Sometimes, the first guard would stop a note because it looked too similar to an old one, preventing the second guard from ever seeing that it was actually a contradiction that needed to be resolved.
- The Fix: They realized the order of operations was wrong. The system needs to check for contradictions before it checks for simple duplicates.
5. The Big Takeaway
The paper concludes that building AI memory for teams isn't just about making the AI "smarter" or giving it a bigger memory window. It's a systems engineering problem.
It's like building a database for a bank, not just a diary for a person. You need strict rules, identity checks, and synchronized clocks. If you treat AI memory like a simple chat history, the system will eventually leak secrets, spread lies, or confuse the agents.
In short: To make AI teams work together safely, we need to stop treating memory like a conversation and start treating it like a secure, governed database.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.