Worker Agents Shouldn't Write Memory Directly: A Curator-Agent Pattern

In a multi-agent setup, shared memory pollution is a familiar pain. One developer on r/openclaw describes a pattern that gates all memory writes through a dedicated Memory Curator agent, preventing worker agents from writing durable facts directly. The approach is inspired by organizational transactive memory research (Ren & Argote) and existing agent memory systems like MemGPT, MemoryBank, LEGOMem, and Generative Agents.

How the Memory Curator Pattern Works

Worker agents never write to memory. Instead, they emit structured memory events with a proposed scope and evidence. The Memory Curator agent then validates, redacts, deduplicates, and routes each event to one of four scopes, or discards it outright.

The Four Scopes

• Agent Repo Memory — durable design decisions for a single agent (analogous to individual specialist memory)
• Agent Team Memory — cross-agent procedures, handoff standards, safety rules (transactive team memory)
• Project Memory — current state, decisions, risks for one engagement
• Session Scratch — temporary observations that probably shouldn't survive (short-term working memory)

Event Schema

Events are JSON with type tags: fact, decision, preference, risk, procedure, hypothesis, plus an evidence reference and a proposed scope. The curator can override the proposed scope and is the only writer to durable stores.

Open Questions

The author flags two concerns:

1. Over-emission or under-emission — the event requirement might cause workers to emit everything (flooding) or stop bothering (losing useful observations).
2. Routing accuracy at scale — session vs. project boundaries blur on long sessions; project vs. team boundaries blur when a lesson generalizes.

The repo is at github.com/jeongmk522-netizen/agent_memory_curator_agent. The developer is curious whether others gate writes up front or do cleanup passes later, noting that cleanup-after is easier but pollution probably accumulates faster than it gets removed.